Compose: Docker Compose monte les volumes nommés en tant que « root » exclusivement

Je ne pense pas que cela soit pris en charge par le moteur docker, nous ne pouvons donc pas le prendre en charge dans Compose tant qu'il n'est pas ajouté à l'API. Cependant, je ne pense pas qu'il soit nécessaire d'ajouter cette fonctionnalité. Vous pouvez toujours attribuer les fichiers au bon utilisateur :

version: '2'
services:
  web:
    image: alpine:3.3
    volumes: ['random:/path']

volumes:
  random:

$ docker-compose run web sh
/ # touch /path/foo
/ # ls -l /path
total 0
-rw-r--r--    1 root     root             0 Apr  5 16:11 foo
/ # chown postgres:postgres /path/foo
/ # ls -l /path
total 0
-rw-r--r--    1 postgres postgres         0 Apr  5 16:11 foo
/ # 

$ docker-compose run web sh
/ # ls -l /path
total 0
-rw-r--r--    1 postgres postgres         0 Apr  5 16:11 foo

Le problème auquel vous êtes confronté concerne l'initialisation d'un volume nommé. Ce n'est certes pas quelque chose qui est géré par Compose (car c'est un peu hors de portée), mais vous pouvez facilement utiliser le docker cli pour initialiser un volume nommé avant d'exécuter docker-compose up .

En effet, je ne savais pas s'il s'agissait d'un problème Docker ou Compose, désolé si je l'avais mal classé.
Est-ce un plan dans l'API Docker, dois-je signaler un problème là-bas ?

Je comprends la possibilité de se connecter manuellement au conteneur et de chown -ing le volume à l'utilisateur 'postgres'. Mais le fait est que, dans mon cas, j'utilise Compose afin que je puisse immédiatement instancier de nouveaux conteneurs pour de nouveaux clients ( docker-compose -p client_name up ) et Compose créera un réseau personnalisé client_name_default , il créera les conteneurs avec les noms client_name _appserver_1 et client_name _server-postgresql_1 et _plus important_, il créera le volume client_name_db-data . Tout cela que je n'ai pas à faire manuellement, il peut donc être exécuté par le script qui gère l'enregistrement du client.

Avec la solution que vous avez décrite (_manuellement_ "connexion" dans le conteneur avec sh et chown -ing le nom de volume), je ne peux pas avoir une procédure simple pour ajouter de nouveaux clients, et cela doit être pris en charge à la main.

C'est pourquoi je pense que cette fonctionnalité devrait être implémentée. Dans l'API Docker, nous pouvons spécifier des autorisations ro ou rw (pour lecture seule ou lecture-écriture) lors du montage d'un volume, je pense que nous devrions pouvoir spécifier user:group .

Qu'en pensez-vous, ma demande a-t-elle un sens?

En fait, je viens ici avec des nouvelles, il semble que ce que j'essaie de réaliser soit faisable, mais je ne sais pas s'il s'agit d'une fonctionnalité ou d'un bogue. Voici pourquoi j'ai changé :

Dans mon Dockerfile , _avant de passer à l'utilisateur 'postgres'_ j'ai ajouté ceci :

# ...
RUN    mkdir /volume_data
RUN   chown postgres:postgres /volume_data

USER postgres
# ...

Cela crée un répertoire /volume_data et modifie ses autorisations afin que l'utilisateur 'postgres' puisse écrire dessus.
C'est la partie Dockerfile .

Maintenant, je n'ai rien changé sur le docker-compose.yml : donc docker-compose crée toujours le volume nommé directory_name_db-data et le monte sur /volume_data et les autorisations ont persisté ! .
Ce qui signifie que maintenant, mon volume nommé est monté sur le répertoire _pre-existing_ /volume_data avec les autorisations conservées, donc 'postgres' peut y écrire.

Alors, s'il s'agit du comportement prévu ou d'une violation de la sécurité ? (Cela me sert dans ce cas, cependant !)

Je pense que cela a été ajouté dans Docker 1.10.x afin que les volumes nommés soient initialisés à partir du premier conteneur qui les a utilisés. Je pense que c'est un comportement attendu.

Je crée également des volumes nommés avec la propriété définie dans le Dockerfile et dans la composition, j'ajoute user: postgres afin que même le PID 1 appartienne à un utilisateur non root.

Docker-compose pour volumes a driver_opts pour fournir des options.
Ce sera très bien de voir des options comme chmod , chown même pour le conducteur local .
Et surtout, je veux qu'il soit également appliqué aux répertoires hôtes créés localement s'il n'est pas présent au démarrage.

Connexe (dans une certaine mesure) https://github.com/moby/moby/pull/28499

Quelqu'un a-t-il déjà ouvert un problème sur le projet Moby ?

La réponse de @dnephin ne fonctionne pas. Le problème est que nous exécutons le conteneur en tant qu'utilisateur standard, les commandes chown ou chmod échouent, le volume étant détenu par root, un utilisateur standard ne peut pas modifier les autorisations.

@jcberthon la méthode suggérée consiste à exécuter le conteneur avec root en tant qu'utilisateur de départ, puis à utiliser la commande USER APRÈS le chown/chmod afin qu'il "supprime essentiellement les privilèges".

C'est bien si vous contrôlez l'image Docker, mais si vous utilisez des images existantes, ce n'est pas vraiment une option.

@dragon788 et @micheljung , j'ai résolu mon problème.

En fait, le vrai problème était que dans mon Dockerfile, j'ai déclaré un VOLUME , puis j'ai modifié la propriété et les autorisations des fichiers dans ce volume. Ces changements sont perdus. En déplaçant simplement la déclaration VOLUME à la fin du Dockerfile (ou en la supprimant, car elle est facultative), mon problème est résolu. Les autorisations sont correctes.

L'erreur était donc :

FROM blabla
RUN do stuff
VOLUME /vol
RUN useradd foo && chown -R foo /vol
USER foo
CMD ["blabla.sh"]

Les chown dans l'exemple Dockerfile ci-dessus sont perdus pendant la construction car nous déclarons VOLUME avant. Lors de l'exécution du conteneur, dockerd copie dans le volume nommé le contenu de /vol avant la déclaration VOLUME (donc avec les autorisations root). Par conséquent, les processus en cours ne peuvent pas modifier ou changer les autorisations, donc même forcer chown dans le script blabla.sh ne peut pas fonctionner.

En changeant le fichier en :

FROM blabla
RUN do stuff
RUN useradd foo && chown -R foo /vol
USER foo
VOLUME /vol
CMD ["blabla.sh"]

le problème est résolu.

@jcberthon pourriez-vous s'il vous plaît partager comment liez-vous votre volume / vol avec le système hôte dans votre docker-compose.yml ?

Je travaille avec Docker sur Fedora (donc, SELinux activé) et aucune des méthodes mentionnées ci-dessus n'a fonctionné pour moi. Idéalement, je souhaite exécuter des applications dans mes conteneurs dans le contexte d'un utilisateur (pas de racine), mais ce problème de volume est un obstacle à cela.

La seule solution de contournement qui fonctionne pour moi consiste à éliminer l'utilisateur de mon application et à tout exécuter/posséder en tant qu'utilisateur root.

Salut @renanwilliam et @egee-irl

J'ai utilisé la solution mentionnée ci-dessus sur plusieurs systèmes d'exploitation, y compris. Fedora 26 et CentOS 7 avec SELinux appliqué, Ubuntu 16.04, 17.10 et Raspbian 9 avec AppArmor activé (avec un mélange de plates-formes amd64 et armhf).

Donc, comme je l'ai dit, j'ai maintenant déplacé la déclaration VOLUME ... à la fin de mon Dockerfile, mais vous pouvez la supprimer complètement, ce n'est pas nécessaire. Ce que je fais aussi habituellement, c'est de corriger l'ID utilisateur lors de la création de l'utilisateur dans le Dockerfile (par exemple useradd -u 8002 -o foo ). Ensuite, je peux simplement réutiliser cet UID sur l'hôte pour donner les autorisations appropriées au dossier.

L'étape suivante consiste donc à créer le "pendant" du répertoire /vol sur l'hôte, disons que c'est /opt/mycontainer1/vol , donc c'est

$ sudo mkdir -p /opt/mycontainer1/vol
$ sudo chown -R 8002 /opt/mycontainer1/vol
$ sudo chmod 0750 /opt/mycontainer1/vol

Ensuite, lors de l'exécution du conteneur en tant qu'utilisateur foo, il pourra écrire dans le répertoire /opt/mycontainer1/vol . Quelque chose comme:

$ sudo -u docker-adm docker run --name mycontainer1 -v /opt/mycontainer1/vol:/vol mycontainer1-img

Sur les hôtes basés sur SELinux, vous souhaiterez peut-être ajouter l'option :z :Z pour le volume afin que Docker balise le dossier de manière appropriée. La différence entre z et Z est que la minuscule z balisera le volume afin que potentiellement tous les conteneurs de cet hôte puissent être autorisés par SELinux à accéder à ce répertoire (mais évidemment uniquement si vous le liez à un autre conteneur), tandis que les majuscules Z le baliseront de sorte que seul ce conteneur spécifique puisse accéder au répertoire. Donc, sur Fedora avec SELinux, vous voudrez peut-être essayer :

$ sudo -u docker-adm docker run --name mycontainer1 -v /opt/mycontainer1/vol:/vol:Z mycontainer1-img

Mise à jour : vous pouvez consulter mon dépôt ici https://github.com/jcberthon/unifi-docker J'utilise cette méthode et explique comment configurer l'hôte et exécuter votre conteneur. J'espère que cela pourra vous aider à résoudre vos problèmes.

Au fait, je m'excuse @renanwilliam pour le long retard à vous répondre. Je n'ai pas beaucoup de temps libre en cette fin d'année...

Alors, bref pour les impatients :

RUN mkdir /volume_data
RUN chown postgres:postgres /volume_data

Créer le répertoire du volume au préalable et un chown résout, car le volume conservera les autorisations du répertoire préexistant.

C'est une mauvaise solution car elle n'est pas évidente (faire un chown dans un Dockerfile puis hériter de cette propriété pendant le montage). Exposer le contrôle du propriétaire et du groupe au niveau de la CLI docker-compose et docker serait le chemin le moins surprenant pour les commandes de style unix.

@villasv

Un petit conseil : fusionnez les 2 RUN ... en un seul, cela évite de créer des calques supplémentaires et c'est une bonne pratique. Donc vos 2 lignes devraient être

RUN mkdir /volume_data && chown postgres:postgres /volume_data

Mais attention (comme je l'ai mentionné dans un commentaire ci-dessus), vous devez exécuter la commande RUN ... ci-dessus avant de déclarer le volume (ou de ne pas déclarer le volume) en utilisant VOLUME ... . Si vous effectuez (comme je l'ai fait) le changement de propriétaire après avoir déclaré le volume, alors ces changements ne sont pas enregistrés et perdus.

@colbygk ce serait effectivement pratique, mais ce n'est pas comme ça que Linux fonctionne. Docker utilise l'espace de noms de montage Linux pour créer différentes hiérarchies à répertoire unique ( / et sous-dossiers), mais autant que je sache, il n'y a pas de mappages d'utilisateurs/groupes ou d'autorisations remplaçant actuellement dans l'espace de noms de montage Linux. Ces "montages" à l'intérieur d'un conteneur (et qui incluent des volumes à montage lié) se trouvent sur un système de fichiers sur l'hôte (à moins que vous n'utilisiez d'autres plugins de volume Docker bien sûr), et ce système de fichiers respecte la couche Linux VFS qui fait tout la vérification des autorisations de fichier. Il pourrait même y avoir sur l'hôte un MAC (par exemple SELinux, AppArmor, etc.) qui pourrait interférer avec l'accès d'un conteneur aux fichiers du conteneur. En fait, si vous faites chroot , vous pouvez rencontrer des problèmes similaires car vous pouvez lier des dossiers de montage dans le chroot, vous avez également le problème que les processus s'exécutant dans l'environnement chroot peuvent avoir le mauvais UID/GID effectif pour accéder aux fichiers dans le montage de liaison.

Des règles Linux simples (et en fait Unix également) s'appliquent au conteneur. L'astuce consiste à voir et à comprendre les possibilités et les limites des espaces de noms Linux aujourd'hui, puis il devient plus clair comment résoudre des problèmes tels que ce problème. Je l'ai entièrement résolu en utilisant les commandes Unix classiques.

@jcberthon Merci pour votre réponse réfléchie :

Je dirais que cela devrait être un problème qui est poussé dans la couche de plug-in comme vous le suggérez et pourrait donc faire partie du plug-in de gestionnaire de volume générique fourni avec Docker. Il me semble très uncloud/container de forcer une ressource externe (externe à un conteneur particulier) à adhérer à des relations essentiellement statiques qui sont définies dans l'image dont un conteneur est dérivé.

Il existe d'autres exemples de ce type exact de mappage uid/gid qui se produit dans d'autres domaines similaires de "unix":

• http://man7.org/linux/man-pages/man5/nfsidmap.5.html
• http://wiki.lustre.org/UID/GID_Mapping
• https://docs.oracle.com/cd/E19120-01/open.solaris/820-2429/mapusergroupidentities/index.html
• https://github.com/zfsonlinux/zfs/issues/4177

S'il vous plait corrigez moi si je me trompe; https://github.com/zfsonlinux/zfs/issues/4177 semble provenir du "leader de LXC/LXD" comme un problème lié à ZFS sur Linux ne fournissant pas correctement les informations UID/GID pour permettre le mappage de ceux-ci dans un conteneur de la manière _exacte_ dont nous discutons ici. En regardant de près https://github.com/zfsonlinux/zfs/issues/4177, il semble que le type de volume zfs pourrait déjà prendre en charge ce mappage uid/gid entre les espaces de noms, mais n'expose pas les contrôles pour le faire.

la plupart des gens qui utilisent Docker sont pour dev/CI, nous utilisons des images "génériques" telles que php/nginx (runner) ou gradle/python (builder) donc une bonne solution sera :

1. pas besoin de créer/modifier Dockerfile pour remplacer l'image
2. utiliser une syntaxe simple dans le fichier yml docker-compose

Puisque nous pouvons facilement décider de l'autorisation d'écriture d'un volume (X:X:OPTION_READ_WRITE), qu'en est-il de l'ajout de la même manière, le propriétaire ?

SOURCE:TARGET:RW:OWNER

J'ai le même problème. Il y a probablement une meilleure pratique, et ma méthode n'est pas celle-ci :

version: '3.5'
services:
    something:
        image: someimage
        user: '1000'
        expose:
            - 8080
        volumes:
            - dev:/app

volumes:
    dev:

Cela provoque EACCES: permission denied, access '/app' .

Comment devrions-nous faire cela? C'est-à-dire définir un nouveau volume et pouvoir y accéder avec un utilisateur non root ?

Salut @Redsandro

Il serait préférable que vous définissiez dans l'image Docker someimage l'UID à 1000 pour /app . Ou si vous ne pouvez pas contrôler cela, vous devez utiliser pour user: ... dans votre fichier de composition l'UID ou le GID qui était prévu par l'auteur de l'image.

Bien sûr, si l'auteur de l'image a utilisé l'UID 0 et que vous ne souhaitez pas exécuter le service en tant que root (et il peut s'exécuter en tant qu'utilisateur sans privilège), alors soulevez un problème auprès de l'auteur de l'image Docker.

@Redsandro Vérifiez les solutions de contournement à partir de : Docker et --userns-remap, comment gérer les autorisations de volume pour partager des données entre l'hôte et le conteneur ?

comme ce n'est pas quelque chose que docker doit gérer, vous pouvez créer un autre conteneur pour provisionner vos volumes juste avant le démarrage des conteneurs associés, par exemple en utilisant https://hub.docker.com/r/hasnat/volumes-provisioner

version: '2'
services:
  volumes-provisioner:
    image: hasnat/volumes-provisioner
    environment:
      PROVISION_DIRECTORIES: "65534:65534:0755:/var/data/prometheus/data"
    volumes:
      - "/var/data:/var/data"

  prometheus:
    image: prom/prometheus:v2.3.2
    ports:
      - "9090:9090"
    depends_on:
      - volumes-provisioner
    volumes:
      - "/var/data/prometheus/data:/prometheus/data"

Je ne comprends pas pourquoi Docker ne répare pas celui-ci, je suis d'accord que nous pouvons le pirater à des fins de développement, mais en production, pas du tout !

IMHO podman est capable de fonctionner en tant qu'utilisateur (non privilégié) (voir aussi ici ) et résoudra probablement ce problème. Quelqu'un travaille également sur une solution de composition et l'API Podman est intentionnellement compatible avec Docker dans la plupart des cas.

[podman] pourrait cependant aider certaines personnes ici, car il est compatible avec Docker en grande partie.

Tout à fait d'accord, malheureusement podman ne fonctionne pas sur Mac

Tout à fait d'accord, malheureusement podman ne fonctionne pas sur Mac

Je ne suis plus un utilisateur d'OS/X mais je viens de voir qu'il existe un _experimental_ podman dmg .

Je suppose qu'un écosystème similaire pourrait se développer dans un avenir proche car il est déjà possible d' accéder à podman-compose .

Cela devient particulièrement un problème lorsque les utilisateurs sans droits sudo sur un cluster partagé créent accidentellement des dossiers appartenant à root via docker-compose et qu'ils ne peuvent même pas supprimer ces dossiers eux-mêmes.

Je suis également tombé sur ce problème. Nous essayons d'utiliser docker dans docker comme indiqué dans

Nous voulons démarrer ce conteneur à partir du fichier docker-compose et pouvoir monter le socket docker de la machine hôte dans la machine conteneur sous le groupe docker. C'est pour que nous puissions utiliser un autre utilisateur autre que root pour exécuter docker depuis l'intérieur du conteneur.

Actuellement, comme je ne peux pas spécifier la propriété et l'autorisation des fichiers de montage de liaison, cela n'est pas réalisable.

Mettez mes deux cents ici :

Pour une solution "native" de docker-compose, j'ai fait ceci, car la plupart des gens auront déjà alpine dans leur bibliothèque d'images:

volumes:
  media:
services:
  mediainit:
    image: alpine
    entrypoint: /bin/sh -c "chown -v nobody:nogroup /mnt/media && chmod -v 777 /mnt/media"
    container_name: mediainit
    restart: "no"
    volumes: 
      - "media:/mnt/media"

Pas la plus sûre des méthodes bien sûr, mais seuls les conteneurs qui ont des privilèges sur le conteneur le verront donc ce n'est pas si grave, mais vous pouvez facilement le faire chown user:user ou faire un peu de fantaisie si votre noyau prend en charge ce.

EDIT: Il semble que vous devez d'abord chown le dossier avant chmod ou il ne "colle" pas, du moins dans mes tests.

la propriété du volume n'est pas sous le contrôle de docker-compose, donc cette discussion devrait avoir lieu sous le dépôt de projet moby.

Quelques notes pour les personnes qui recherchent ici une solution de contournement :
Le volume Docker, lorsqu'il est utilisé pour la première fois par un conteneur, obtient son contenu initial et l'autorisation héritée du conteneur. Ce qui signifie que vous pouvez configurer votre image comme ceci :

#Dockerfile
FROM alpine
RUN addgroup -S nicolas && adduser -S nicolas -G nicolas
RUN mkdir /foo && chown nicolas:nicolas /foo  
# empty, but owned by `nicolas`. Could also have some initial content
VOLUME /foo  
USER nicolas

Une telle image, lorsqu'elle est exécutée sans volume explicite (qui sera créé exprès avec un ID aléatoire) ou avec un volume nommé qui n'existe pas encore, « propagera » les autorisations sur le volume :

➜  docker run --rm -it -v some_new_volume:/foo myimage
/ $ ls -al /foo
total 8
drwxr-xr-x    2 nicolas  nicolas       4096 Oct 18 08:30 .
drwxr-xr-x    1 root     root          4096 Oct 18 08:30 ..

La même chose s'applique lors de l'utilisation de volumes déclarés dans un fichier de composition :

#docker-compose.yml
version: "3"
services:
  web:
    image: myimage
    command: ls -al /foo
    volumes:
      - db-data:/foo
volumes:
    db-data:

➜  docker-compose up
Creating volume "toto_db-data" with default driver
Creating toto_web_1 ... done
Attaching to toto_web_1
web_1  | total 8
web_1  | drwxr-xr-x    2 nicolas  nicolas       4096 Oct 18 08:30 .
web_1  | drwxr-xr-x    1 root     root          4096 Oct 18 08:37 ..
toto_web_1 exited with code 0

Cela ne fonctionnera pas si vous rattachez un volume qui a déjà été utilisé par un autre conteneur. La modification de la propriété du volume ou son contrôle au moment de la création doit être implémentée par le moteur ou par les pilotes de volume avec des options spécifiques. Sinon, vous devrez vous fier à quelques chown trucs comme suggéré ^.

J'espère que cela t'aides.
Je ferme ce problème car compose n'a aucun contrôle sur la création de volume mais l'API du moteur exposé.