Recientemente, alguien abrió un problema en Podman.io:¿Tiene sentido Dockerfile USER para podman? El usuario estaba intentando configurar un contenedor para ejecutar un contenedor de Postgresql como no root. Quería crear un directorio para la base de datos de Postgresql en su directorio de inicio y montarlo en volumen en el contenedor:
$ 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
¿Tiene sentido ejecutar Podman sin root como no root?
El problema que estaba teniendo era que el directorio que creó en el directorio de inicio, $PWD/html era propiedad de su UID. Este UID se parece a root dentro del contenedor, y el proceso de Postgresql dentro del contenedor no se ejecuta como raíz:se ejecuta como postgres usuario (-u postgres ). Por lo tanto, el proceso de Postgresql no puede escribir en el directorio.
La solución fácil a este problema es cortar el html directorio para que coincida con el UID con el que se ejecuta Postgresql dentro del contenedor. Sin embargo, si el usuario intenta cortar el archivo:
chown postgres:postgres $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Obtienen el permiso denegado. Este resultado se debe a que el usuario no es root en el sistema y no se le permite convertir archivos en UID aleatorios:
$ grep postgres /etc/passwd
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
Si el usuario agrega sudo para chown el directorio, obtendrán un error similar. Ahora el directorio es propiedad del UID 26, pero el UID 26 no está asignado al contenedor y no es el mismo UID con el que se ejecuta Postgres mientras está en el contenedor. Recuerde de mis artículos anteriores sobre el espacio de nombres de usuario que Podman lanza un contenedor dentro del espacio de nombres de usuario, que se asigna con el rango de UID definidos para el usuario en /etc/subuid y /etc/subgid .
En mi sistema, corro con este espacio de nombres de usuario:
$ podman unshare cat /proc/self/uid_map
0 3267 1
1 100000 65536
Este resultado muestra que el UID 0 se asigna a mi UID, 3267, mientras que el UID 1 se asigna a 100000, el UID 2 se asigna a 100001, y así sucesivamente. Este resultado significa que dentro del contenedor, el UID 26 se ejecuta como UID 100025.
Excelente, probemos eso:
$ chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Operation not permitted
Bueno, eso tampoco funcionó. El problema es que aunque mi cuenta de usuario puede ejecutar un espacio de nombres de usuario con estas asignaciones, actualmente no estoy en un espacio de nombres de usuario. Necesito usar el podman unshare comando, que lo coloca en el mismo espacio de nombres de usuario que usa Podman sin raíz, por lo que las cosas se ven exactamente igual para unshare como lo hacen para rootless:
$ podman unshare chown 100025:100025 $PWD/html
chown: changing ownership of '/home/dwalsh/html': Invalid argument
Error: exit status 1
Todavía incorrecto. El problema ahora es que el chown está sucediendo dentro del espacio de nombres del usuario, por lo que chown necesita usar el UID original, no el UID asignado:
$ podman unshare chown 26:26 $PWD/html
Fuera del espacio de nombres de usuario, este resultado se ve así:
$ ls -ld $PWD/html
drwxrwxr-x. 2 100025 100025 4096 Sep 13 07:14 /home/dwalsh/html
Ahora, cuando el usuario ejecuta el contenedor, tiene éxito. El proceso de Postgresql dentro del contenedor se ejecuta como UID 26 dentro del contenedor (y 100025 fuera).
Pero volvamos a la pregunta original:"¿Tiene sentido ejecutar Podman sin root como no root?" Si ya está ejecutando el contenedor como no root, ¿por qué debería ejecutar Postgresql como no root diferente en el contenedor Podman?
De forma predeterminada, Podman sin raíz se ejecuta como raíz dentro del contenedor. Esta política significa que los procesos en el contenedor tienen la lista predeterminada de capacidades de espacios de nombres que permiten que los procesos actúen como root dentro del espacio de nombres del usuario, incluido el cambio de su UID y la conversión de archivos a diferentes UID que se asignan al espacio de nombres del usuario. Si desea ejecutar el contenedor como usuario de Postgresql, desea evitar este acceso.
Esta configuración también significa que los procesos dentro del contenedor se ejecutan como el UID del usuario. Si el proceso del contenedor escapó del contenedor, el proceso tendría acceso completo a los archivos en su directorio de inicio según la separación de UID. SELinux seguiría bloqueando el acceso, pero he oído que algunas personas deshabilitan SELinux . Si lo hace, significa que el proceso escapado podría leer los secretos en su directorio de inicio, como ~/.ssh y ~/.gpg u otra información a la que preferiría que el contenedor no tuviera acceso.
Sin embargo, si ejecuta los procesos dentro del contenedor como un UID no raíz diferente, esos procesos se ejecutarán como ese UID. Si escapan del contenedor, solo tendrían acceso mundial al contenido en su directorio de inicio. Tenga en cuenta que para trabajar con el contenido de estos directorios, debe ejecutar podman unshare o configure la propiedad del grupo de directorios como propiedad de su UID (raíz dentro del contenedor).
Con Podman, desea permitir que los usuarios ejecuten cualquier imagen de contenedor en cualquier registro de contenedor como no root si el usuario así lo desea. Y creo que ejecutar contenedores como no root siempre debe ser su principal prioridad por razones de seguridad.
[¿Quiere probar Red Hat Enterprise Linux? Descárguelo ahora gratis.]