Un problema clave que tienen los usuarios de Podman es acceder a archivos y dispositivos que pueden usar desde el host pero que no pueden usar mientras están en un contenedor, incluso si montan los objetos en volumen en el contenedor.
En este caso, vamos a ver el acceso de grupo suplementario. A menudo, los sistemas se configuran con archivos y dispositivos a los que solo pueden acceder grupos específicos de usuarios. Por ejemplo, estoy en la rueda group en mi sistema, lo que permite a mi usuario acceder a algunos controles administrativos. Los administradores pueden configurar un directorio para que lo compartan varios usuarios en el sistema creando el eng grupo, agregando usuarios al eng grupo, y luego permitir que el eng grupo para tener el directorio rwx permisos Ahora todos los usuarios en eng puede leer y escribir el directorio.
Recientemente recibimos un problema en el que un usuario tenía problemas para dar acceso a un dispositivo GPU en su sistema.
Estaba agregando el dispositivo usando un comando como:
$ podman run --device /dev/video0 … Nota :En contenedores sin raíz, los usuarios sin raíz no pueden crear nuevos dispositivos al agregar un dispositivo a un contenedor. Así que Podman simplemente enlaza monta el dispositivo desde el contenedor hasta el host. Cuando está en modo rootfull, se crea un nuevo dispositivo al que tienen acceso los procesos dentro del contenedor.
El volumen de Podman se monta en /dev/video0 , pero cada vez que el usuario intenta usar el dispositivo dentro del contenedor falla con Permiso denegado . Sin embargo, cuando revisó el dispositivo en el host y los grupos de los que era miembro, todo parecía correcto. Por ejemplo:
$ ls -l /dev/video0
crw-rw----+ 1 root video 81, 0 May 3 14:06 /dev/video0
$ groups
dwalsh video Puede usar completamente el dispositivo fuera de los contenedores. Darse cuenta de que el proceso del contenedor no está en el video grupo, luego pensó en agregar el video group al contenedor para obtener acceso. Intentó este comando:
$ podman run --group-add video --device /dev/video0 … Pero aun así falló con Permiso denegado .
¿Qué pasó?
Cuando usas --group-add video , agrega el video grupo definido dentro de la imagen del contenedor al proceso principal del contenedor, así:
$ grep video /etc/group
video: 39:
$ podman run --group-add video fedora id
uid=0(root) gid=0(root) groups=0(root),39(video)
Dentro del contenedor, el proceso tiene el grupo 39 , pero esto no lo mismo que el grupo 39 en el anfitrión. Cuando ejecuta contenedores sin raíz, está utilizando el espacio de nombres de usuario para que el grupo se compense con el espacio de nombres de usuario al que se ha unido. Aquí está el espacio de nombres:
$ podman unshare cat /proc/self/gid_map
0 3267 1
1 100000 65536
Esto significa que el vídeo el grupo dentro del contenedor será GID 100038 en el anfitrión. Echa un vistazo a este ejemplo:
$ ctr=$(podman run -d --group-add video fedora sleep 100)
$ pid=$(podman top -l hpid | tail -1)
$ grep Groups /proc/$pid/status
Groups: 100038 Para acceder al dispositivo de video en el host, el proceso necesita GID=39 real , por lo que falla. Los usuarios sin root no pueden forzar el acceso al GID=39 real en el host ya que las protecciones estándar de Linux lo bloquean.
Podman al rescate
A partir de Podman 3.2, agregamos una nueva característica, --group-add keep-groups , que funciona con el tiempo de ejecución de OCI crun . Normalmente, cuando inicia un contenedor Podman, el tiempo de ejecución de OCI ejecuta los setgroups llamada al sistema; esto cambia el proceso principal dentro del contenedor para obtener los grupos definidos dentro del contenedor y también elimina el acceso a los grupos de procesos principales. Por lo general, esto es lo que desea que suceda, ya que no desea que un proceso escapado de un contenedor obtenga acceso a su rueda grupo, por ejemplo.
Cuando ejecuta con --group-add keep-groups , el tiempo de ejecución del contenedor OCI (crun ) no llama a los setgroups , por lo que el nuevo proceso contenedor mantiene los grupos de su proceso padre. Si el proceso principal tiene acceso a GID=39 , los procesos dentro del contenedor seguirán teniendo ese grupo y podrán usar el dispositivo.
$ podman run --device /dev/video0 --group-add keep-group … ¡Y todo funciona!
[ ¿Empezando con los contenedores? Consulta este curso gratuito. Implementación de aplicaciones en contenedores:una descripción técnica general. ]
Anexo
Tenga en cuenta que dentro del contenedor, el GID 39 no está mapeado, por lo que los procesos dentro del contenedor lo verán como nadie grupo. Se ve así:
$ ./bin/podman run --group-add keep-groups fedora groups
root nobody
Las versiones anteriores de Podman tienen una interfaz menos fácil de usar para activar este comportamiento en crun . Agregando la --annotation run.oci.keep_original_groups=1 , crun no ejecutará setgroups .
$ podman run --annotation run.oci.keep_original_groups=1 --device /dev/video0
Si usa --group-add keep-groups llamada, no puede configurar otros grupos dentro del contenedor. En cambio, el contenedor solo puede heredar los grupos de los padres. La razón de esto es que Podman requiere los setgroups llame para establecer grupos adicionales dentro del contenedor, y esto perdería el acceso a los grupos de los padres. Giuseppe Scrivano ha propuesto dos parches para permitir setgroups en esta situación. Este enfoque aún está en discusión. Giuseppe también ha abierto un problema con runtime-spec para hacer de esto una parte formal de la especificación y ponerlo en otros tiempos de ejecución de oci como runc , pero tampoco se ha fusionado todavía.
Resumir
Los usuarios de Podman tienen problemas para acceder a archivos y dispositivos dentro de un contenedor, incluso cuando los usuarios tienen acceso a esos recursos en el host. Examinamos casos de uso en los que se expone este problema y discutimos algunos de los parches propuestos para abordar el problema.
[ Descargar ahora:una guía para administradores de sistemas sobre secuencias de comandos Bash. ]