Un problema chiave che gli utenti Podman stanno riscontrando è l'accesso a file e dispositivi che possono utilizzare dall'host ma che non possono utilizzare mentre si trovano in un container, anche se montano gli oggetti nel container.
In questo caso, esamineremo l'accesso di gruppo supplementare. Spesso i sistemi sono configurati con file e dispositivi accessibili solo a specifici gruppi di utenti. Ad esempio, sono nella ruota gruppo sul mio sistema, che consente al mio utente di accedere ad alcuni controlli amministrativi. Gli amministratori possono impostare una directory da condividere da più utenti sul sistema creando il eng gruppo, aggiungendo utenti al eng gruppo e quindi consentendo il eng gruppo per avere la directory rwx permessi. Ora tutti gli utenti in eng può leggere e scrivere la directory.
Di recente abbiamo ricevuto un problema per cui un utente faticava a fornire l'accesso a un dispositivo GPU sul suo sistema.
Stava aggiungendo il dispositivo usando un comando come:
$ podman run --device /dev/video0 … Nota :nei container rootless, gli utenti rootless non possono creare nuovi dispositivi quando aggiungono un dispositivo a un container. Quindi Podman si limita a montare il dispositivo dal contenitore all'host. In modalità rootfull, viene creato un nuovo dispositivo a cui hanno accesso i processi all'interno del contenitore.
Il volume Podman si monta in /dev/video0 , ma ogni volta che l'utente tenta di utilizzare il dispositivo all'interno del contenitore non riesce con Autorizzazione negata . Tuttavia, quando ha controllato il dispositivo sull'host e i gruppi di cui era membro, tutto sembrava corretto. Ad esempio:
$ ls -l /dev/video0
crw-rw----+ 1 root video 81, 0 May 3 14:06 /dev/video0
$ groups
dwalsh video Può utilizzare completamente il dispositivo al di fuori dei contenitori. Rendersi conto che il processo del contenitore non è nel video gruppo, ha quindi pensato di aggiungere il video gruppo al contenitore per ottenere l'accesso. Ha provato questo comando:
$ podman run --group-add video --device /dev/video0 … Ma ha comunque fallito con Autorizzazione negata .
Cosa è successo?
Quando utilizzi --group-add video , aggiunge il video gruppo definito all'interno dell'immagine del contenitore al processo principale del contenitore, in questo modo:
$ grep video /etc/group
video: 39:
$ podman run --group-add video fedora id
uid=0(root) gid=0(root) groups=0(root),39(video)
All'interno del contenitore, il processo ha il gruppo 39 , ma questo non lo stesso del gruppo 39 sull'ospite. Quando si eseguono contenitori senza root, si utilizza lo spazio dei nomi utente in modo che il gruppo sia compensato dallo spazio dei nomi utente a cui si è unito. Ecco lo spazio dei nomi:
$ podman unshare cat /proc/self/gid_map
0 3267 1
1 100000 65536
Ciò significa che il video gruppo all'interno del contenitore sarà GID 100038 sull'ospite. Dai un'occhiata a questo esempio:
$ ctr=$(podman run -d --group-add video fedora sleep 100)
$ pid=$(podman top -l hpid | tail -1)
$ grep Groups /proc/$pid/status
Groups: 100038 Per accedere al dispositivo video sull'host, il processo necessita di GID=39 reali , quindi fallisce. Gli utenti rootless non possono forzare l'accesso al GID=39 reale sull'host poiché le protezioni standard di Linux lo bloccano.
Podman in soccorso
A partire da Podman 3.2, abbiamo aggiunto una nuova funzionalità, --group-add keep-groups , che funziona con il runtime OCI crun . Normalmente, quando avvii un contenitore Podman, il runtime OCI esegue i setgroups chiamata di sistema; questo cambia il processo principale all'interno del contenitore per ottenere i gruppi definiti all'interno del contenitore e elimina anche l'accesso ai gruppi di processi padre. Di solito, questo è ciò che vuoi che accada poiché non vuoi che un processo sfuggito da un container ottenga l'accesso al tuo ruota gruppo, per esempio.
Quando esegui con --group-add keep-groups , il runtime del contenitore OCI (crun ) non chiama i setgroup , quindi il nuovo processo contenitore mantiene i gruppi del processo padre. Se il processo principale ha accesso a GID=39 , i processi all'interno del contenitore avranno ancora quel gruppo e potranno utilizzare il dispositivo.
$ podman run --device /dev/video0 --group-add keep-group … E tutto funziona!
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Addendum
Tieni presente che all'interno del contenitore, il GID 39 non è mappato, quindi i processi all'interno del contenitore lo vedranno come nessuno gruppo. Si presenta così:
$ ./bin/podman run --group-add keep-groups fedora groups
root nobody
Le versioni precedenti di Podman hanno un'interfaccia meno intuitiva per attivare questo comportamento in crun . Aggiungendo il --annotation run.oci.keep_original_groups=1 , crun non eseguirà setgroups .
$ podman run --annotation run.oci.keep_original_groups=1 --device /dev/video0
Se utilizzi --group-add keep-groups chiamata, non è possibile impostare altri gruppi all'interno del contenitore. Al contrario, il contenitore può ereditare solo i gruppi del padre. Il motivo è che Podman richiede i setgroups chiamata per impostare gruppi aggiuntivi all'interno del contenitore e ciò perderebbe l'accesso ai gruppi del genitore. Giuseppe Scrivano ha proposto due patch per consentire setgroups in questa situazione. Questo approccio è ancora in discussione. Giuseppe ha anche aperto un problema con le specifiche di runtime per renderlo una parte formale della specifica e inserirlo in altri oci-runtime come runc , ma non è ancora stato unito.
Concludi
Gli utenti Podman riscontrano problemi nell'accesso a file e dispositivi all'interno di un container, anche quando gli utenti hanno accesso a tali risorse sull'host. Abbiamo esaminato i casi d'uso in cui questo problema è esposto e discusso alcune delle patch proposte per risolvere il problema.
[ Scarica ora:una guida per l'amministratore di sistema allo scripting Bash. ]