Recentemente, qualcuno ha aperto un problema su Podman.io:Dockerfile USER ha senso per podman? L'utente stava tentando di configurare un contenitore per eseguire un contenitore Postgresql come non root. Voleva creare una directory per il database Postgresql nella sua home directory e montarla nel contenitore:
$ podman run -it **-v "$PWD"/html:/output:Z** schemaspy/schemaspy:snapshot -u postgres -t pgsql11 -host 192.168.4.1 -port 5432 -db anitya
...
INFO - Starting Main v6.1.0-SNAPSHOT on 9090a61652af with PID 1 (/schemaspy-6.1.0-SNAPSHOT.jar started by java in /)
INFO - The following profiles are active: default
INFO - Started Main in 2.594 seconds (JVM running for 3.598)
INFO - Starting schema analysis
**ERROR - IOException**
**Unable to create directory /output/tables**
INFO - StackTraces have been omitted, use `-debug` when executing SchemaSpy to see them
Ha senso eseguire Podman senza root come non root?
Il problema che stava riscontrando era che la directory che aveva creato nella directory home, $PWD/html era di proprietà del suo UID. Questo UID assomiglia a root all'interno del contenitore e il processo Postgresql all'interno del contenitore non viene eseguito come root:viene eseguito come postgres utente (-u postgres ). Pertanto, il processo Postgresql non è in grado di scrivere nella directory.
La soluzione più semplice a questo problema è chown il html directory in modo che corrisponda all'UID con cui Postgresql viene eseguito all'interno del contenitore. Tuttavia, se l'utente tenta di chownare il file:
chown postgres:postgres $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Ottengono il permesso negato. Questo risultato è dovuto al fatto che l'utente non è root sul sistema e non è autorizzato a chownare i file su UID casuali:
$ grep postgres /etc/passwd
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
Se l'utente aggiunge sudo per chown la directory, riceveranno un errore simile. Ora la directory è di proprietà dell'UID 26, ma l'UID 26 non è mappato nel contenitore e non è lo stesso UID con cui Postgres viene eseguito mentre si trova nel contenitore. Ricordo dai miei precedenti articoli sullo spazio dei nomi utente che Podman avvia un contenitore all'interno dello spazio dei nomi utente, che è mappato con l'intervallo di UID definito per l'utente in /etc/subuid e /etc/subgid .
Sul mio sistema, eseguo questo spazio dei nomi utente:
$ podman unshare cat /proc/self/uid_map
0 3267 1
1 100000 65536
Questo risultato mostra che l'UID 0 è mappato al mio UID, 3267, mentre l'UID 1 è mappato a 100000, l'UID 2 è mappato a 100001 e così via. Questo risultato significa che all'interno del contenitore, l'UID 26 viene eseguito come UID 100025.
Eccellente, proviamolo:
$ chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Ebbene, neanche quello ha funzionato. Il problema è che anche se il mio account utente può eseguire uno spazio dei nomi utente con queste mappature, al momento non sono in uno spazio dei nomi utente. Devo usare podman unshare comando, che ti porta nello stesso spazio dei nomi utente utilizzato da Podman senza root, quindi le cose sembrano esattamente le stesse per unshare come fanno per i rootless:
$ podman unshare chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Invalid argument
Error: exit status 1
Ancora errato. Il problema ora è che il chown sta accadendo all'interno dello spazio dei nomi utente, quindi chown deve utilizzare l'UID originale, non l'UID mappato:
$ podman unshare chown 26:26 $PWD/html
Al di fuori dello spazio dei nomi utente, questo risultato è simile a:
$ ls -ld $PWD/html
drwxrwxr-x. 2 100025 100025 4096 Sep 13 07:14 /home/dwalsh/html
Ora, quando l'utente esegue il contenitore, ha esito positivo. Il processo Postgresql all'interno del contenitore viene eseguito come UID 26 all'interno del contenitore (e 100025 all'esterno).
Ma torniamo alla domanda originale:"Ha senso eseguire Podman senza root come non root?" Se stai già eseguendo il contenitore come non root, perché dovresti eseguire Postgresql come un diverso non root nel contenitore Podman?
Per impostazione predefinita, Podman senza root viene eseguito come root all'interno del contenitore. Questo criterio significa che i processi nel contenitore hanno l'elenco predefinito di capacità con spazio dei nomi che consentono ai processi di agire come root all'interno dello spazio dei nomi utente, inclusa la modifica del proprio UID e il chowning dei file su UID diversi mappati nello spazio dei nomi utente. Se vuoi eseguire il container come utente Postgresql, vuoi impedire questo accesso.
Questa configurazione significa anche che i processi all'interno del contenitore sono in esecuzione come UID dell'utente. Se il processo del contenitore è sfuggito al contenitore, il processo avrebbe pieno accesso ai file nella directory home in base alla separazione dell'UID. SELinux bloccherebbe comunque l'accesso, ma ho sentito che alcune persone disabilitano SELinux . Ciò significa che il processo di escape potrebbe leggere i segreti nella tua home directory, come ~/.ssh e ~/.gpg o altre informazioni a cui preferiresti che il contenitore non avesse accesso.
Tuttavia, se esegui i processi all'interno del contenitore come un UID non root diverso, tali processi verranno eseguiti come tale UID. Se sfuggono al container, avranno solo accesso mondiale al contenuto nella tua home directory. Nota che per lavorare con il contenuto in queste directory, devi eseguire un podman unshare comando o imposta la proprietà del gruppo delle directory come di proprietà del tuo UID (root all'interno del contenitore).
Con Podman, vuoi consentire agli utenti di eseguire qualsiasi immagine contenitore su qualsiasi registro contenitore come non root se l'utente lo desidera. E credo che l'esecuzione di container come non root debba sempre essere la tua priorità assoluta per motivi di sicurezza.
[Vuoi provare Red Hat Enterprise Linux? Scaricalo ora gratuitamente.]