Deux options que j'ai trouvées :
CHOWN toutes les choses (après avoir fait votre travail)
J'ai fait docker run -v `pwd`/shared:/shared image , et le conteneur a créé des fichiers dans pwd/shared qui appartiennent au processus docker. Cependant, /shared m'appartient toujours. Donc, dans le processus docker, je fais
chown -R `stat -c "%u:%g" /shared` /shared
stat -c "%u:%g" /shared renvoie 1000:1000 dans mon cas, étant le uid:gid de mon utilisateur. Même s'il n'y a pas d'utilisateur 1000 dans le docker conatainer, l'id est là (et stat /shared dit simplement "inconnu" si vous demandez le nom d'utilisateur).
Quoi qu'il en soit, chown transfère docilement la propriété du contenu de /shared à 1000:1000 (qui, pour sa part, n'existe pas, mais hors du contenant, c'est moi). Je possède donc maintenant tous les fichiers. Le conteneur peut toujours modifier les choses s'il le souhaite, car de son point de vue, c'est root .
Et tout va bien dans le monde.
docker run -u ainsi tous les fichiers créés auront automatiquement le bon propriétaire
Une autre façon de faire est le -u indicateur lors de l'exécution du menu fixe.
docker run -v `pwd`/shared:/shared -u `stat -c "%u:%g" /shared` ubuntu bash
De cette façon, l'utilisateur docker à l'intérieur du conteneur est youruid:yourgid .
Cependant : cela signifie renoncer à votre autorité racine dans le conteneur (apt-get install , etc.). Sauf si vous créez un utilisateur avec ce nouvel uid et l'ajoutez au root groupe.
Est-ce exact? Quelqu'un peut-il m'indiquer la documentation à ce sujet, je ne fais que conjecturer sur la base de l'expérience ci-dessus.
C'est peut-être simplement parce qu'ils ont tous les deux la même valeur numérique sur le noyau, et si je testais sur un système où mon utilisateur personnel n'était pas id 1000, les autorisations seraient modifiées dans tous les cas ?
Avoir une lecture de info coreutils 'chown invocation' , cela pourrait vous donner une meilleure idée du fonctionnement des autorisations/de la propriété des fichiers.
Fondamentalement, cependant, chaque fichier sur votre machine a un ensemble de bits qui définit ses autorisations et sa propriété. Lorsque vous chown un fichier, vous ne faites que définir ces bits.
Lorsque vous chown un fichier à un utilisateur/groupe particulier en utilisant le nom d'utilisateur ou le nom de groupe, chown cherchera dans /etc/passwd pour le nom d'utilisateur et /etc/group pour que le groupe tente de mapper le nom à un ID. Si le nom d'utilisateur / nom de groupe n'existe pas dans ces fichiers, chown échouera.
[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'
Cependant, vous pouvez chown un fichier utilisant les identifiants de ce que vous voulez (dans certaines limites supérieures d'entiers positifs, bien sûr), qu'il existe ou non un utilisateur / groupe avec ces identifiants sur votre machine.
[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
Les bits UID et GID sont définis sur le fichier lui-même, donc lorsque vous montez ces fichiers dans votre conteneur Docker, le fichier a le même UID de propriétaire/groupe que sur l'hôte, mais est maintenant mappé sur /etc/passwd dans le conteneur, qui sera probablement un utilisateur différent à moins qu'il n'appartienne à root (UID 0).
La vraie question est, bien sûr, « qu'est-ce que je fais à ce sujet ? Si bob est connecté en tant que bob sur la machine hôte donnée, il devrait pouvoir exécuter le conteneur en tant que bob et ne pas modifier les autorisations de fichiers sous son compte hôte. Dans l'état actuel des choses, il doit en fait exécuter le conteneur en tant qu'utilisateur docker pour éviter que son compte ne soit modifié.
Il semble qu'avec votre configuration actuelle, vous devrez vous assurer que vos UID > noms d'utilisateur sont en /etc/passwd sur votre hébergeur correspondent à vos UIDs> noms d'utilisateurs dans vos conteneurs /etc/passwd si vous souhaitez interagir avec votre répertoire utilisateur monté en tant que même utilisateur connecté sur l'hôte.
Vous pouvez créer un utilisateur avec un identifiant d'utilisateur spécifique avec useradd -u xxxx . Buuuut, cela semble être une solution désordonnée...
Vous devrez peut-être trouver une solution qui ne monte pas le répertoire d'accueil des utilisateurs hôtes.
Donc, je me suis retrouvé dans ce post en cherchant comment restaurer la propriété de tous les fichiers (appartenant à root) qui sont sortis d'un conteneur docker fonctionnant en tant que root , à mon utilisateur non privilégié dans l'hôte.
J'avais besoin que le processus à l'intérieur du conteneur s'exécute en tant que root, donc je ne peux pas utiliser -u sur docker run.
Je ne suis pas fier de ce que j'ai fait, mais à la fin de mon script bash, j'ai ajouté ceci :
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/'
Décomposons certaines lignes :
- Exécutez /bin/sh à l'intérieur du conteneur :
--entrypoint /bin/sh
- Passez l'uid de l'utilisateur actuel en tant que variable d'environnement au conteneur :
-e HOST_UID=`id -u`
- Montez le dossier que vous souhaitez redonner à votre utilisateur (rempli de fichiers appartenant à root, générés par le conteneur précédent qui s'exécutait en tant que root ), sous le
/tmpde ce nouveau conteneur :
-v ${HOST_FOLDER_OWNED_BY_ROOT} :/tmp
- Exécuter
chownrécursivement avec l'uid de l'utilisateur hôte sur le répertoire cible (monté à l'intérieur du conteneur en/tmp):
-c 'chown -R ${HOST_UID} :${HOST_UID} /tmp/'
Ainsi, avec cela, j'ai récupéré les fichiers appartenant à mon utilisateur actuel sans avoir à "élever" les privilèges vers root ou vers sudo.
C'est sale, mais ça a marché. J'espère que j'ai aidé.