Ejecute Podman sin root como usuario no root

Recientemente alguien abrió un tema sobre 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 tuvo fue que el directorio que creó en el directorio de inicio, $PWD/html pertenecía a su UID. Este UID parece root dentro del contenedor, y el proceso de Postgresql dentro del contenedor no se ejecuta como root: 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 chown the 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 que ejecuta Postgres cuando está en el contenedor. recordatorio de mi artículos anteriores en el espacio de nombres de usuario, Podman lanza un contenedor dentro del espacio de nombres de usuario, que se asigna con el rango de UID definido para el usuario en /etc/subuid y /etc/subgid.

En mi sistema, estoy corriendo con este espacio de nombre de usuario:

$ podman unshare cat /proc/self/uid_map
      0    3267      1
      1    100000    65536

Este resultado muestra que UID 0 se asigna a mi UID, 3267, mientras que UID 1 se asigna a 100000, UID 2 se asigna a 100001, y así sucesivamente. Este resultado significa que dentro del contenedor, el UID 26 se ejecuta como UID 100025.

Genial, probemos esto:

$ 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 nombre de usuario que usa Podman sin root, 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 ocurre dentro del espacio de nombres del usuario, por lo que chown debe utilizar 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 root se ejecuta como root en el contenedor. Esta política significa que los procesos en el contenedor tienen la lista predeterminada que permite que los procesos actúen como raíz dentro del espacio de nombres del usuario, incluido el cambio de su UID y el chowning de archivos a diferentes UID que se asignan al espacio de nombres del usuario. Si desea ejecutar el contenedor como un 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 se 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 . Esto significa que el proceso escapado podría leer secretos de su directorio de inicio, como ~/.ssh y ~/.gpgu otra información a la que preferiría que el contenedor no tuviera acceso.

Sin embargo, si ejecuta los procesos en el contenedor como un UID no root diferente, esos procesos se ejecutarán bajo ese UID. Si escapan del contenedor, solo tendrán acceso al contenido de su directorio de inicio. Tenga en cuenta que para trabajar con el contenido de estos directorios, debe ejecutar un podman unshare comando, o establezca la propiedad del grupo de los directorios para que pertenezcan a 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.

Artículos de interés

Subir