podman: container fără rădăcină: permisiuni pentru utilizatorul containerului

În nginx container podman nginx utilizatorul este obișnuit să ruleze nginx Server.

Pe mașina gazdă ls -alh:

drwxrwx--- 2 utilizatorul meu utilizatorul meu 4.0K 10 august 22:23.
drwxrwx--- 3 utilizatorul meu utilizatorul meu 4.0K 10 august 22:59 ..
-rw-rw---- 1 myuser myuser 46 Aug 10 22:24 .htpasswd

Același folder în interiorul containerului ls -alh:

drwxrwx--- 2 root root 4.0K Aug 10 22:23 .
drwxr-xr-x 1 rădăcină rădăcină 4.0K 10 august 11:05 ..
-rw-rw---- 1 rădăcină rădăcină 46 Aug 10 22:24 .htpasswd

nginx utilizatorul din interiorul containerului nu poate accesa .htpasswd din cauza o-rwx.

Întrebare: care este modelul folosit în mod obișnuit pentru a gestiona acest tip de cazuri fără rădăcini container universal? Poate că este posibil să creați un grup (utilizat mai târziu ca proprietar al grupului de fișiere) care adună toate intervalele de la subuid/subgid pentru un anumit utilizator gazdă - dar cum se realizează acest lucru?

Prin utilizarea opțiunii de linie de comandă --uidmap puteți specifica modul în care utilizatorul meu UID și utilizatorul meu sub UID-urile sunt mapate în container. (Vezi pagina de manual pentru podman alerga).

Opțiunea de linie de comandă --gidmap funcționează în același mod, dar pentru GID-uri în loc de UID-uri.

Să căutăm UID-ul și GID-ul utilizatorului nginx în imaginea containerului docker.io/library/nginx

$ podman run --rm docker.io/library/nginx grep nginx /etc/passwd
nginx:x:101:101:nginx user,,,:/inexistent:/bin/false
$

Rezultat:

• UID: 101
• GID: 101

Numerele sunt utilizate mai târziu la setarea a două variabile shell

$ container_uid=101
$ container_gid=101

(Variabilele shell container_uid și container_gid nu au nicio semnificație în afara acestei postări. Sunt introduse doar pentru a face răspunsul mai ușor de citit)

Aruncă o privire în fișierele /etc/subuid și /etc/subgid de pe gazdă

Utilizatorul utilizatorul meu are aceste sub-UID-uri și sub-GID-uri.

$ grep myuser /etc/subuid
utilizatorul meu:231072:65536
$ grep utilizatorul meu /etc/subgid
utilizatorul meu:231072:65536
$ 

Rezultat:

utilizatorul meu are 65536 sub-UID-uri și 65536 sub-GID-uri.

Numerele sunt utilizate mai târziu la setarea a două variabile shell

$ subuid_size=65536
$ subgid_size=65536

(Variabilele shell subuid_size și subgid_size nu au nicio semnificație în afara acestei postări. Sunt introduse doar pentru a face răspunsul mai ușor de citit)

În loc să ridici privirea subuid_size și subgid_size în /etc/subuid și /etc/subgid, o metodă mai generală este să rulați comenzile

 subuid_size=$(( $(podman info --format "{{ range .Host.IDMappings.UIDMap }}+{{.Size }}{{end }}" ) - 1 ))
 subgid_size=$(( $(podman info --format "{{ range .Host.IDMappings.GIDMap }}+{{.Size }}{{end }}" ) - 1 ))

Avantajul este că acest lucru funcționează și atunci când fișierul /etc/nsswitch.conf este folosit în loc de /etc/subuid și /etc/subgid. (Vedea om subuid)

Demo 1: harta utilizatorul utilizatorul meu pe gazdă către utilizator rădăcină în interiorul recipientului

Nu este nevoie să specificați --uidmap nici --gidmap deoarece aceasta este maparea standard.

Creați directorul mondial de scriere demo1

$ mkdir demo1
$ chmod 777 demo1
$

Creați un fișier nou, rulând ca rădăcină in interiorul recipientului:

$ podman run --rm \
    -v ./demo1:/dir:Z \
      docker.io/library/nginx touch /dir/created_by_root
$

Creați un fișier nou, rulând ca nginx in interiorul recipientului:

$ podman run --rm \
    --utilizator 101:101 \
    -v ./demo1:/dir:Z \
      docker.io/library/nginx touch /dir/created_by_nginx
$

Listați fișierele de pe gazdă

$ ls -l demo1
total 0
-rw-r--r--. 1 231172 231172 0 Aug 27 20:24 create_by_nginx
-rw-r--r--. 1 myuser myuser 0 Aug 27 20:22 created_by_root
$ 

Rezultat: Dosarul creat_de_rădăcină este deținută de utilizatorul meu:utilizatorul meu

Demo 2: harta utilizatorul utilizatorul meu pe gazdă către utilizator nginx în interiorul recipientului

Creați directorul mondial de scriere demo2

$ mkdir demo2
$ chmod 777 demo2
$

Creați un fișier nou, rulând ca rădăcină in interiorul recipientului:

$ subuid_size=65536
$ subgid_size=65536
$ container_uid=101
$ container_gid=101
$ podman run --rm \
    --uidmap=0:1:$container_uid \
    --uidmap=$((container_uid + 1)):$((container_uid + 1)):$((subuid_size - $container_uid)) \
    --uidmap=$container_uid:0:1 \
    --gidmap=0:1:$container_gid \
    --gidmap=$((container_gid + 1)):$((container_gid + 1)):$((subgid_size - $container_gid)) \
    --gidmap=$container_gid:0:1 \
    -v ./demo2:/dir:Z \
      docker.io/library/nginx touch /dir/created_by_root
$

Creați un fișier nou, rulând ca nginx în interiorul recipientului.

$ subuid_size=65536
$ subgid_size=65536
$ container_uid=101
$ container_gid=101
$ podman run --rm \
    --user $container_uid:$container_gid \
    --uidmap=0:1:$container_uid \
    --uidmap=$((container_uid + 1)):$((container_uid + 1)):$((subuid_size - $container_uid)) \
    --uidmap=$container_uid:0:1 \
    --gidmap=0:1:$container_gid \
    --gidmap=$((container_gid + 1)):$((container_gid + 1)):$((subgid_size - $container_gid)) \
    --gidmap=$container_gid:0:1 \
    -v ./demo2:/dir:Z \
      docker.io/library/nginx touch /dir/created_by_nginx
$

Listați fișierele de pe gazdă

$ ls -l demo2
total 0
-rw-r--r--. 1 myuser myuser 0 Aug 27 20:26 created_by_nginx
-rw-r--r--. 1 231072 231072 0 Aug 27 20:25 created_by_root
$ 

Rezultat: Dosarul creat_de_nginx este deținută de utilizatorul meu:utilizatorul meu

Concluzie

Utilizare --uidmap și --gidmap în același mod ca în Demo 2.

Sfat de depanare

Am scris un sfat de depanare: Dispozitivele sau fișierele transmise nu pot fi accesate în containerul fără rădăcină (problema de mapare UID/GID) care contine metoda descrisa in Demo 2

Ar trebui să vă dați seama care este UID-ul gazdă inițial pentru containerul nginx UID (doar atingeți un fișier din container folosind utilizatorul sub care nginx rulează sau verificați fișierele jurnal sau verificați rularea nginx proces. Apoi folosiți stat sau ls -ln de la utilizatorul gazdă inițial): o valoare UID mare, să presupunem că este 100030.

Apoi, de la utilizatorul neprivilegiat al gazdei inițiale, puteți utiliza setfactl pentru a acorda acces suplimentar utilizatorului 100030. Acesta ar trebui să fie ceva de genul:

setfacl -R -m u:100030:rX,d:u:100030:rX folder

Daca vrei ca nginx utilizator pentru a putea scrie (ceea ce s-ar putea să nu fie o idee bună), puteți înlocui rX cu rwX sau faceți-o numai în directoare selectate. Dublarea începând cu d: reprezintă Mod implicit ACL-urile, deci directoarele și fișierele nou create moștenesc, de asemenea, aceleași ACL-uri suplimentare. Când ACL-urile sunt setate, ieșirea de ls afișează a + și masca ACL în loc de grup, așa că ar putea părea surprinzător.

Iată diferite referințe despre ACL-uri:

• README-ul Debian LXC (care mi-a dat ideea),
• Liste de control al accesului POSIX pe Linux
• acl(5)