Dos opciones que he encontrado:
CHOWN todas las cosas (después de hacer tu trabajo)
He hecho docker run -v `pwd`/shared:/shared image y el contenedor ha creado archivos dentro de pwd/shared que son propiedad del proceso docker. Sin embargo, /shared sigue siendo de mi propiedad. Así que dentro del proceso docker, lo hago
chown -R `stat -c "%u:%g" /shared` /shared
stat -c "%u:%g" /shared devuelve 1000:1000 en mi caso, siendo el uid:gid de mi usuario. Aunque no hay ningún usuario 1000 dentro del contenedor docker, la identificación está allí (y stat /shared solo dice "desconocido" si le pide el nombre de usuario).
De todos modos, chown transfiere obedientemente la propiedad de los contenidos de /shared a 1000:1000 (que, por lo que a él respecta, no existe, pero fuera del contenedor, soy yo). Así que ahora soy dueño de todos los archivos. El contenedor todavía puede modificar cosas si quiere, porque desde su perspectiva, es root .
Y todo está bien en el mundo.
docker run -u por lo que todos los archivos creados tendrán automáticamente el propietario correcto
Otra forma de hacer esto es el -u marca en la ejecución de la ventana acoplable.
docker run -v `pwd`/shared:/shared -u `stat -c "%u:%g" /shared` ubuntu bash
De esta forma, el usuario de la ventana acoplable dentro del contenedor es youruid:yourgid .
Sin embargo: esto significa renunciar a su autoridad de root dentro del contenedor (apt-get install , etc.). A menos que cree un usuario con ese nuevo uid y lo agregue al root grupo.
¿Es eso correcto? ¿Puede alguien señalarme la documentación de esto? Solo estoy conjeturando en base al experimento anterior.
¿Quizás esto se debe a que ambos tienen el mismo valor numérico en el kernel, y si probé en un sistema donde mi usuario doméstico no era id 1000, entonces los permisos cambiarían en todos los casos?
Tener una lectura de info coreutils 'chown invocation' , eso podría darle una mejor idea de cómo funcionan los permisos/la propiedad de los archivos.
Básicamente, sin embargo, cada archivo en su máquina tiene un conjunto de bits agregados que definen sus permisos y propiedad. Cuando chown un archivo, solo está configurando estos bits.
Cuando chown un archivo a un usuario/grupo en particular utilizando el nombre de usuario o nombre de grupo, chown buscará en /etc/passwd para el nombre de usuario y /etc/group para que el grupo intente asignar el nombre a una ID. Si el nombre de usuario/grupo no existe en esos archivos, chown fallará.
[email protected]:/test# touch test
[email protected]:/test# ll
total 8
drwxr-xr-x 2 root root 4096 Oct 22 18:15 ./
drwxr-xr-x 22 root root 4096 Oct 22 18:15 ../
-rw-r--r-- 1 root root 0 Oct 22 18:15 test
[email protected]:/test# chown test:test test
chown: invalid user: 'test:test'
Sin embargo, puede chown un archivo que usa ID para lo que quieras (dentro de algunos límites superiores de números enteros positivos, por supuesto), ya sea que haya un usuario/grupo que exista con esas ID en tu máquina o no.
[email protected]:/test# chown 5000:5000 test
[email protected]:/test# ll
total 8
drwxr-xr-x 2 root root 4096 Oct 22 18:15 ./
drwxr-xr-x 22 root root 4096 Oct 22 18:15 ../
-rw-r--r-- 1 5000 5000 0 Oct 22 18:15 test
Los bits de UID y GID se configuran en el propio archivo, por lo que cuando monta esos archivos dentro de su contenedor docker, el archivo tiene el mismo UID de propietario/grupo que tiene en el host, pero ahora está asignado a /etc/passwd en el contenedor, que probablemente será un usuario diferente a menos que sea propiedad de root (UID 0).
La verdadera pregunta es, por supuesto, '¿qué debo hacer al respecto?' Si bob está conectado como bob en la máquina anfitriona dada, debería poder ejecutar el contenedor como bob y no modificar los permisos de archivo en su cuenta de host. Tal como está, en realidad necesita ejecutar el contenedor como ventana acoplable de usuario para evitar que se altere su cuenta.
Parece que, con su configuración actual, deberá asegurarse de que sus UID> nombres de usuario en /etc/passwd en su host coincida con sus UID> nombres de usuario en sus contenedores /etc/passwd si desea interactuar con su directorio de usuarios montado como el mismo usuario que inició sesión en el host.
Puede crear un usuario con una identificación de usuario específica con useradd -u xxxx . Buuuut, eso parece una solución complicada...
Es posible que deba encontrar una solución que no monte un directorio de inicio de usuarios de host.
Entonces, terminé en esta publicación buscando cómo restaurar la propiedad de todos los archivos (propiedad de root) que salieron de un contenedor docker ejecutándose como root , a mi usuario sin privilegios en el host.
Necesitaba que el proceso dentro del contenedor se ejecutara como raíz, por lo que no puedo usar -u en la ejecución de la ventana acoplable.
No estoy orgulloso de lo que hice, pero al final de mi script bash, agregué esto:
docker run --rm -it \
--entrypoint /bin/sh \
-e HOST_UID=`id -u` \
-v ${HOST_FOLDER_OWNED_BY_ROOT}:/tmp \
alpine:latest \
-c 'chown -R ${HOST_UID}:${HOST_UID} /tmp/'
Desglosemos algunas de las líneas:
- Ejecute /bin/sh dentro del contenedor:
--punto de entrada /bin/sh
- Pase el uid del usuario actual como una variable de entorno al contenedor:
-e HOST_UID=`id -u`
- Monte cualquier carpeta que desee volver a poseer para su usuario (llena de archivos propiedad de root, generada por el contenedor anterior que se ejecutó como root ), bajo el
/tmpde este nuevo contenedor :
-v ${HOST_FOLDER_OWNED_BY_ROOT}:/tmp
- Ejecutar
chownrecursivamente con el uid del usuario del host sobre el directorio de destino (montado dentro del contenedor en/tmp):
-c 'chown -R ${HOST_UID}:${HOST_UID} /tmp/'
Entonces, con esto, le devolví los archivos a mi usuario actual sin tener que "escalar" los privilegios a root o sudo.
Está sucio, pero funcionó. Espero haber ayudado.