A volte gli utenti si interrogano sui vincoli della modalità rootless per i motori di container Buildah e Podman. Con la modalità rootless, stiamo spingendo i confini di ciò che un utente non privilegiato può fare. Uno dei miei lavori è lavorare con i team del kernel e dei file system per migliorare il rootless. In questo articolo spiego perché montare le immagini è più difficile in modalità rootless.
[ Potrebbe piacerti anche: Bilanciare la sicurezza di Linux con l'usabilità ]
Montaggio senza radici
Un utente normale non può montare un filesystem a meno che non si trovi in uno spazio dei nomi utente insieme al proprio spazio dei nomi di montaggio . Uno spazio dei nomi di montaggio consente ai processi al suo interno di montare file system che non sono visti dallo spazio dei nomi di montaggio dell'host. Questo vincolo del kernel protegge il sistema operativo host da potenziali attacchi in cui un utente potrebbe montare contenuti su /tmp o anche nella loro home directory e quindi ingannare altri processi sul sistema o gli amministratori per utilizzare i punti di montaggio.
Una volta che il processo dell'utente si unisce allo spazio dei nomi utente e al nuovo spazio dei nomi di montaggio, il kernel consente solo il montaggio di determinati file system. Al momento della stesura di questo documento, il kernel consente i file system sysfs, procfs, tmpfs, bind mount e fuse. Recentemente abbiamo ricevuto una patch nel kernel upstream per supportare i file system overlay, il che rappresenterà un grande miglioramento, ma attualmente la maggior parte delle distribuzioni non ha questo supporto. Mi piacerebbe ottenere il supporto NFS, ma ci sono rischi per la sicurezza con questo. Si spera che il kernel risolva questi problemi e, alla fine, sarà supportato.
I motori di container senza root come Podman e Buildah creano automaticamente il proprio spazio dei nomi utente e montano lo spazio dei nomi quando vengono eseguiti. Quando il processo del motore del contenitore si chiude, gli spazi dei nomi di montaggio e utente scompaiono e il processo utente torna allo spazio dei nomi di montaggio dell'host. A questo punto, i mount creati durante l'esecuzione degli strumenti non sono più visibili o utilizzabili da altri processi sull'host.
Perché è importante?
Una delle caratteristiche interessanti di Buildah è quella di consentire agli utenti di accedere alla semantica di basso livello della costruzione di container. La maggior parte dei costruttori di immagini di container sono bloccati con un solo modo per creare container, fondamentalmente usando Containerfiles o Dockerfiles. Buildah bud supporta la creazione con questi file. Buildah consente inoltre agli utenti di creare contenitori utilizzando primitive di basso livello. Gli utenti possono utilizzarlo per creare una directory, popolare la directory con il contenuto, creare un'immagine e inviarla a un registro.
# ctr=$(buildah from scratch)
# mnt=$buildah mount $ctr)
# dnf -y --install-root $mnt httpd
# buildah config --entrypoint .... $ctr
# buildah commit $ctr IMAGE
# buildah push IMAGE REGISTRY Tutto funziona alla grande quando viene eseguito come root, ma quando gli utenti tentano di eseguirlo in modalità rootless, i loro script esplodono.
$ mnt=$(buildah mount $ctr)
cannot mount using driver overlay in rootless mode. You need to run it in a `buildah unshare` session
Il problema è mnt=$(buildah mount $ctr) rifiuta di montare l'immagine con il driver overlay se non hai eseguito buildah unshare .
Dando un'occhiata più da vicino
Quando esegui buildah comandi, come bud e run , in modalità rootless, il buildah comando immette l'utente e monta gli spazi dei nomi. Monta correttamente il file system del contenitore ed esegue i comandi. Al termine del comando, buildah esce, provocando la distruzione degli spazi dei nomi. Quando lo fai con il mount comando, il file system montato non è mai stato visto nello spazio dei nomi di montaggio dell'host. Buildah ora verifica questa situazione e segnala all'utente che deve emettere un buildah unshare prima.
buildah annulla condivisione
Buildah e Podman hanno un comando speciale, unshare . Questo comando crea e immette lo spazio dei nomi utente senza creare o interagire con un contenitore. In realtà è abbastanza interessante esplorare questa modalità per comprendere appieno cosa sta facendo lo spazio dei nomi utente. Esecuzione di buildah unshare command eseguirà un comando shell negli spazi dei nomi in esecuzione come root nello spazio dei nomi utente. Ora puoi eseguire qualsiasi comando, incluso buildah comandi sopra descritti. Poiché questi comandi sono già negli spazi dei nomi, buildah mount il comando funzionerà allo stesso modo della modalità root. Tutto accade all'interno degli spazi dei nomi e l'utente ottiene ciò che si aspetta.
Ora l'utente può prendere i comandi sopra elencati e creare uno script di shell. Questo script di shell viene quindi eseguito direttamente con buildah unshare comando.
$ cat > buildahimage.sh < _EOF
ctr=$(buildah from scratch)
mnt=$buildah mount $ctr)
dnf -y --install-root $mnt httpd
buildah config --entrypoint .... $ctr
buildah commit $ctr IMAGE
buildah push IMAGE REGISTRY
< _EOF
chmod +x /buildahimage.sh
buildah unshare ./buildimage.sh [ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Concludi
Purtroppo non possiamo riparare tutto all'interno del kernel per offrire agli utenti l'esperienza rootless che si aspettano, principalmente a causa di problemi di sicurezza. Ma possiamo avvicinarci abbastanza. E, naturalmente, puoi sempre lavorare in modalità root se hai bisogno di funzionalità aggiuntive.