Podman sin root y NFS | Activar administrador del sistema

Mucha gente está interesada en Podman sin root. Esta herramienta le permite crear, instalar y jugar con contenedores sin necesidad de que los usuarios se ejecuten como root o tengan un gran demonio root en sus sistemas. En su lugar, Podman (de forma predeterminada) almacena imágenes de contenedores en el directorio de inicio del usuario. Podman aprovecha esto porque la mayoría de las imágenes de contenedor tienen más de un UID en la imagen. Expliqué cómo funciona en artículos anteriores.

Sin embargo, un problema que no funcionará es almacenar estas imágenes en un directorio de inicio basado en NFS.

Índice

    ¿Por qué Podman no admite el almacenamiento a través de NFS?

    Primero déjeme decir que para la mayoría de los casos de uso, Podman sin root funciona bien con un volumen NFS. El caso de uso que funciona bien es que el almacén de imágenes del contenedor resida en un punto de montaje NFS.

    Este problema se comprende más fácilmente cuando un usuario intenta extraer una imagen o instalar un paquete RPM. Echemos un vistazo a lo que sucede cuando un usuario intenta instalar un paquete tarball o RPM en un sistema de archivos usando Podman sin root.

    Para nuestros ejemplos, usaré el usuario myuser con un UID de 1000 y una configuración de tarjeta UID en /etc/subuid se parece a esto:

    myuser:100000:65536
    

    El resultado se ve así:

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

    Ahora dentro del contenedor quiero instalar el httpd paquete. el httpd El paquete instalará los archivos como root y como apache usuario con un UID de 60. Esto significa que el proceso raíz del contenedor que instala el httpd El paquete en su directorio de inicio intenta ejecutar algo como esto:

    $ chown 60:60 /var/www/html/index.html
    

    Cuando esto sucede en un sistema de archivos local, el núcleo verifica dos cosas. Primero, verifica si el UID 60 y el GID 60 están asignados dentro del espacio de nombres del usuario. En segundo lugar, determina si el proceso que realiza el chowning tiene la capacidad DAC_OVERRIDE.

    Dado que el proceso no se ejecuta como UID 60, debería poder anular los permisos normales de UID/GID. El proceso dentro del contenedor se ejecuta como UID 1000 cuando se ejecuta como raíz, cuando se ejecuta como UID 60 dentro del contenedor, se ejecuta como en realidad actúa desde uid 100059 en el host. Tenga en cuenta que solo estoy hablando del espacio de nombre de usuario DAC_OVERRIDE, lo que significa que el proceso dentro del contenedor puede ANULAR un UID/GID asignado en el espacio de nombre de usuario, como el contenedor.

    Esta configuración funciona en todos los sistemas de archivos locales porque el núcleo local puede tomar las decisiones. Cuando se trata de NFS, debe satisfacer tanto el kernel local como el kernel remoto. Y en el caso de NFS, el núcleo remoto hace cumplir las reglas.

    Mire este problema desde la perspectiva del núcleo del servidor NFS remoto. El núcleo remoto ve un proceso que se ejecuta como UID 1000 (raíz en el contenedor) que intenta chmod un archivo propiedad de 1000 con UID 100059 (UID 60 dentro del contenedor). El kernel remoto niega este acceso.

    El protocolo NFS no tiene concepto de espacios de nombres de usuario y no tiene forma de saber que el proceso que se ejecuta bajo UID 1000 está en uno. El servidor NFS tampoco tiene forma de saber que el proceso del cliente tiene DAC_OVERRIDE para el espacio de nombre de usuario y que el UID 100059 está asignado al mismo espacio de nombre de usuario. En otras palabras, las posibilidades de que NFS conozca esta información son, en el mejor de los casos, escasas.

    Ahora, si tiene un proceso normal de creación de archivos en un recurso compartido NFS y no aprovecha las capacidades del espacio de nombres de usuario, todo funciona bien. El problema surge cuando el root El proceso dentro del contenedor debe hacer algo en el recurso compartido de NFS que requiere un acceso de capacidad especial. En este caso, el kernel remoto no conocerá la capacidad y lo más probable es que niegue el acceso.

    ¿Cómo puedo hacer que NFS funcione con Podman sin root?

    Hay varias formas de configurar el directorio de inicio de un usuario en un recurso compartido NFS para usar Podman sin root. Podrías configurar el graphroot bandera en el ~/.config/Contenedores/Almacenamiento.conf archivo para tener un punto de almacenamiento en un directorio que no está en el recurso compartido NFS. Por ejemplo, modifique:

    [storage]  
    driver = "overlay"  
    runroot = "/run/user/1000"  
    graphroot = "/home/myuser/.local/share/Contenedores/Almacenamiento"
    

    en

    [storage]  
    driver = "overlay"  
    runroot = "/run/user/1000"  
    graphroot = "/var/tmp/myuser/Contenedores/Almacenamiento
    

    Este cambio hará que las imágenes extraídas y creadas en el contenedor se procesen en un directorio diferente, que está fuera del directorio base.

    Otra opción sería crear una imagen de disco y montarla en el ~/.local/share/Contenedores directorio telefónico. Puedes usar un script como este:

    truncate -s 10g /home/myuser/xfs.img  
    mkfs.xfs -m reflink=1 /home/myuser/xfs.img
    

    Entonces puedes configurar fstab en máquinas con directorios de inicio para hacer algo como esto:

    $ mount /home/myuser/xfs.img /home/myuser/.local/share/Contenedores
    

    Conclusión

    Rootless y rootfull Podman funcionan muy bien con recursos compartidos de red remotos montados como volúmenes, incluidos los recursos compartidos NFS. Sin embargo, el Podman sin raíz listo para usar no funcionará bien en los directorios principales de NFS porque el protocolo no comprende los espacios de nombres de los usuarios. Afortunadamente, con cambios de configuración menores, puede ejecutar Podman sin root en un directorio de inicio de NFS.

    Artículos de interés

    Subir