Compose: Docker Compose mountet benannte Volumes ausschließlich als 'root'

Ich glaube nicht, dass dies von der Docker-Engine unterstützt wird, daher können wir es in Compose erst dann unterstützen, wenn es der API hinzugefügt wird. Ich glaube jedoch nicht, dass es notwendig ist, diese Funktion hinzuzufügen. Sie können die Dateien immer dem richtigen Benutzer zuordnen:

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

Das Problem, mit dem Sie konfrontiert sind, betrifft die Initialisierung eines benannten Volumes. Dies wird zugegebenermaßen nicht von Compose behandelt (weil es etwas außerhalb des Geltungsbereichs liegt), aber Sie können leicht das Docker-Cli verwenden, um ein benanntes Volume zu initialisieren, bevor Sie docker-compose up ausführen.

Ich war mir in der Tat nicht sicher, ob dies ein Docker- oder ein Compose-Problem war, sorry, wenn ich es falsch abgelegt habe.
Ist dies ein Plan in der Docker-API, sollte ich dort ein Problem melden?

Ich verstehe die Möglichkeit, sich manuell in den Container einzuloggen und chown das Volume an den Benutzer 'postgres' zu übergeben. Aber in meinem Fall verwende ich Compose, damit ich sofort neue Container für neue Clients instanziieren kann ( docker-compose -p client_name up ) und Compose erstellt ein benutzerdefiniertes Netzwerk client_name_default , es erstellt die Container mit den Namen client_name _appserver_1 und client_name _server-postgresql_1 und _noch wichtiger_ wird das Volume client_name_db-data . All das muss ich nicht manuell tun, damit es von dem Skript ausgeführt werden kann, das die Client-Registrierung verarbeitet.

Mit der von Ihnen beschriebenen Lösung (_manuell_ "logging" im Container mit sh und chown -ing der Datenträgerbezeichnung) kann ich kein einfaches Verfahren zum Hinzufügen neuer Clients haben, und dies muss von Hand gepflegt werden.

Aus diesem Grund denke ich, dass diese Funktion implementiert werden sollte. In der Docker-API können wir beim Mounten eines Volumes ro oder rw (für schreibgeschützte oder schreibgeschützte) Berechtigungen angeben. Ich denke, wir sollten in der Lage sein, user:group anzugeben.

Was meint ihr, macht meine Bitte Sinn?

Eigentlich komme ich mit Neuigkeiten hierher, es scheint, dass das, was ich erreichen möchte, machbar ist, aber ich weiß nicht, ob dies ein Feature oder ein Fehler ist. Deshalb habe ich mich geändert:

In meinem Dockerfile habe

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

USER postgres
# ...

Dies bewirkt, dass ein Verzeichnis /volume_data erstellt und seine Berechtigungen geändert werden, damit der Benutzer 'postgres' darauf schreiben kann.
Dies ist der Dockerfile- Teil.

Jetzt habe ich nichts an der docker-compose.yml geändert : also erstellt directory_name_db-data und mountet es auf /volume_data und die Berechtigungen sind bestehen geblieben! .
Das bedeutet, dass ich jetzt mein Named Volume im _pre-existing_ Verzeichnis /volume_data mit den erhaltenen Berechtigungen gemountet habe, damit 'postgres' darauf schreiben kann.

Ist dies also das beabsichtigte Verhalten oder eine Sicherheitsverletzung? (In diesem Fall dient es mir jedoch!)

Ich glaube, dies wurde in Docker 1.10.x hinzugefügt, damit benannte Volumes aus dem ersten Container initialisiert werden, der sie verwendet. Ich denke, es ist erwartetes Verhalten.

Ich mache auch benannte Volumes, bei denen der Besitz in der Dockerfile festgelegt ist, und in Compose füge ich user: postgres sodass sogar PID 1 einem Nicht-Root-Benutzer gehört.

Docker-compose für volumes hat driver_opts , um Optionen bereitzustellen.
Es wird sehr gut sein, dort Optionen wie chmod , chown sogar für den Fahrer local .
Und vor allem möchte ich, dass es auch für lokal erstellte Hostverzeichnisse angewendet wird, wenn es beim Start nicht vorhanden ist.

Verwandte (teilweise) https://github.com/moby/moby/pull/28499

Hat jemand bereits ein Problem zum Moby-Projekt geöffnet?

Die Antwort von @dnephin funktioniert nicht. Das Problem besteht darin, dass wir den Container als Standardbenutzer ausführen, die Befehle chown oder chmod fehlschlagen, das Volume im Besitz von Root ist und ein Standardbenutzer die Berechtigungen nicht ändern kann.

@jcberthon Die vorgeschlagene Methode besteht darin, den Container mit root als USER NACH dem chown/chmod zu verwenden, so dass er im Grunde "Privilegien verwirft".

Das ist in Ordnung, wenn Sie die Kontrolle über das Docker-Image haben, aber wenn Sie vorhandene Images verwenden, ist dies nicht wirklich eine Option.

@dragon788 und @micheljung , ich habe mein Problem gelöst.

Eigentlich war das eigentliche Problem, dass ich in meinem Dockerfile ein VOLUME deklarierte und dann den Besitz und die Berechtigungen der Dateien in diesem Volume änderte. Diese Änderungen gehen verloren. Durch einfaches Verschieben der VOLUME Deklaration an das Ende des Dockerfiles (oder Entfernen, da optional) ist mein Problem gelöst. Die Berechtigungen sind korrekt.

Der Fehler war also:

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

Die chown im obigen Beispiel-Dockerfile gehen während des Builds verloren, weil wir VOLUME davor deklarieren. Beim Ausführen des Containers kopiert dockerd innerhalb des benannten Volumes den Inhalt von /vol vor der VOLUME Deklaration (also mit Root-Berechtigungen). Daher können die laufenden Prozesse keine Berechtigungen ändern oder ändern, so dass selbst das Erzwingen von chown im blabla.sh-Skript nicht funktionieren kann.

Durch Ändern der Datei in:

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

das Problem ist gelöst.

@jcberthon könnten Sie bitte teilen, wie Sie Ihr Volume /vol mit dem Hostsystem in Ihrer docker-compose.yml binden?

Ich arbeite mit Docker auf Fedora (also SELinux aktiviert) und keine der oben genannten Methoden hat bei mir funktioniert. Idealerweise möchte ich Anwendungen in meinen Containern im Kontext eines Benutzers (kein Root) ausführen, aber dieses Volume-Problem blockiert dies.

Die einzige Problemumgehung, die für mich funktioniert, besteht darin, meinen Anwendungsbenutzer zu eliminieren und alles als Root-Benutzer auszuführen/zu besitzen.

Hallo @renanwilliam und @egee-irl

Ich verwende die oben genannte Lösung auf mehreren Betriebssystemen inkl. Fedora 26 und CentOS 7 beide mit erzwungenem SELinux, Ubuntu 16.04, 17.10 und Raspbian 9, alle drei mit aktiviertem AppArmor (mit einer Mischung aus amd64- und armhf-Plattformen).

Also, wie gesagt, ich habe jetzt die VOLUME ... Deklaration an das Ende meiner Dockerfile verschoben, aber Sie können sie alle zusammen entfernen, sie wird nicht benötigt. Was ich normalerweise auch mache, ist die Benutzer-ID beim Anlegen des Benutzers im Dockerfile zu korrigieren (zB useradd -u 8002 -o foo ). Dann kann ich diese UID einfach auf dem Host wiederverwenden, um dem Ordner die richtigen Berechtigungen zu erteilen.

Der nächste Schritt besteht also darin, den "Anhänger" des Verzeichnisses /vol auf dem Host zu erstellen, sagen wir, es ist /opt/mycontainer1/vol , also ist das

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

Wenn der Container dann als Benutzer foo ausgeführt wird, kann er in das Verzeichnis /opt/mycontainer1/vol schreiben. Etwas wie:

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

Auf SELinux-basierten Hosts möchten Sie möglicherweise die Option :z :Z für das Volume hinzufügen, damit Docker den Ordner entsprechend markiert. Der Unterschied zwischen z und Z besteht darin, dass die Kleinbuchstaben z das Volume markieren, sodass möglicherweise allen Containern dieses Hosts von SELinux der Zugriff auf dieses Verzeichnis ermöglicht wird (aber offensichtlich nur wenn Sie es an einen anderen Container binden), während die Großbuchstaben Z es so kennzeichnen, dass nur dieser bestimmte Container auf das Verzeichnis zugreifen kann. Auf Fedora mit SELinux möchten Sie es vielleicht versuchen:

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

Update : Sie können mein Repo hier überprüfen https://github.com/jcberthon/unifi-docker Ich verwende diese Methode und erkläre, wie Sie den Host konfigurieren und Ihren Container ausführen. Ich hoffe, dies kann Ihnen helfen, Ihre Probleme zu lösen.

Übrigens, ich entschuldige mich bei @renanwilliam für die lange Verzögerung bei der Beantwortung. Ich habe am Ende des Jahres nicht viel Freizeit...

Also, lange Rede, kurzer Sinn für Ungeduldige:

RUN mkdir /volume_data
RUN chown postgres:postgres /volume_data

Das Erstellen des Volume-Verzeichnisses im Voraus und ein chown löst das Problem, da das Volume die Berechtigungen des bereits vorhandenen Verzeichnisses beibehält.

Dies ist eine schlechte Lösung, da es nicht offensichtlich ist (Chown in einem Dockerfile ausführen und dann dieses Eigentum während des Mountens erben). Die Freigabe der Eigentümer- und Gruppensteuerung in der Docker-Compose- und Docker-CLI wäre für Befehle im Unix-Stil der am wenigsten überraschende Weg.

@villasv

Ein kleiner Tipp: Führen Sie die 2 RUN ... zu einem zusammen, dies vermeidet das Erstellen zusätzlicher Ebenen und ist eine bewährte Methode. Also sollten deine 2 Zeilen sein

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

Aber Vorsicht (wie ich oben in einem Kommentar erwähnt habe), dass Sie den obigen Befehl RUN ... ausführen müssen, bevor Sie das Volume mit VOLUME ... deklarieren (oder das Volume tatsächlich nicht deklarieren). Wenn Sie (wie ich) den Eigentümerwechsel nach der Deklaration des Volumens vornehmen, werden diese Änderungen nicht aufgezeichnet und gehen verloren.

@colbygk es wäre zwar praktisch, aber so funktioniert Linux nicht. Docker verwendet den Linux-Mount-Namespace, um verschiedene Einzelverzeichnishierarchien ( / und Unterordner) zu erstellen, aber AFAIK gibt es derzeit keine Benutzer-/Gruppenzuordnungen oder Berechtigungen, die im Linux-Mount-Namespace überschreiben. Diese "Mounts" in einem Container (und dazu gehören Bind-Mount-Volumes) befinden sich auf einem Dateisystem auf dem Host (es sei denn, Sie verwenden natürlich andere Docker-Volume-Plugins), und dieses Dateisystem respektiert die Linux-VFS-Schicht, die alles macht die Dateiberechtigungsprüfung. Auf dem Host könnte sogar ein MAC (zB SELinux, AppArmor usw.) vorhanden sein, der den Zugriff eines Containers auf Dateien innerhalb des Containers stören könnte. Wenn Sie chroot tun, können Sie auf ähnliche Probleme stoßen, da Sie Mount-Ordner innerhalb der Chroot binden können die Bindehalterung.

Für den Container gelten einfache Linux- (und eigentlich auch Unix-) Regeln. Der Trick besteht darin, die Möglichkeiten und Grenzen von Linux-Namespaces heute zu erkennen und zu verstehen, und dann wird klarer, wie Probleme wie dieses Problem gelöst werden können. Ich habe es vollständig mit klassischen Unix-Befehlen gelöst.

@jcberthon Vielen Dank für Ihre nachdenkliche Antwort:

Ich würde argumentieren, dass dies ein Problem sein sollte, das wie von Ihnen vorgeschlagen in die Plugin-Schicht verschoben wird und daher Teil des generischen Volume-Handler-Plugins werden könnte, das mit Docker geliefert wird. Es scheint mir sehr uncloud/container zu sein, eine externe Ressource (außerhalb eines bestimmten Containers) zu zwingen, im Wesentlichen statische Beziehungen einzuhalten, die in dem Image definiert sind, von dem ein Container abgeleitet ist.

Es gibt andere Beispiele für diese genaue Art von UID/GID-Mapping, die in anderen ähnlichen Bereichen von "Unix" auftritt:

• 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

Bitte korrigieren Sie mich, wenn ich falsch liege; https://github.com/zfsonlinux/zfs/issues/4177 scheint vom "Führer von LXC/LXD" als ein Problem im Zusammenhang mit ZFS unter Linux entstanden zu sein, das UID/GID-Informationen nicht korrekt bereitstellt, um eine Zuordnung dieser in ein zu ermöglichen Container fast so _exakt_, wie wir es hier besprechen. Wenn man sich https://github.com/zfsonlinux/zfs/issues/4177 genau ansieht, scheint es, dass der Volume-Typ zfs diese uid/gid-Zuordnung zwischen Namespaces tatsächlich bereits unterstützen könnte, aber die Steuerelemente dafür nicht verfügbar macht.

Die meisten Leute, die Docker verwenden, ist für dev / CI, wir verwenden "generische" Images wie php/nginx (runner) oder gradle/python (builder), sodass eine gute Lösung:

1. Dockerfile muss nicht erstellt/bearbeitet werden, um das Image zu überschreiben
2. Verwenden Sie eine einfache Syntax in der docker-compose yml-Datei

Da wir die Schreibberechtigung eines Volumes (X:X:OPTION_READ_WRITE) leicht festlegen können, wie wäre es mit dem Hinzufügen des Eigentümers auf die gleiche Weise?

SOURCE:TARGET:RW:OWNER

Ich habe das gleiche Problem. Es gibt wahrscheinlich eine bewährte Methode, und meine Methode ist _nicht_:

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

volumes:
    dev:

Dies verursacht EACCES: permission denied, access '/app' .

Wie sollen wir das machen? Dh ein neues Volume definieren und mit einem Nicht-Root-Benutzer darauf zugreifen können?

Hallo @Redsandro

Es wäre besser, wenn Sie im someimage Docker-Image die UID auf 1000 für /app . Oder wenn Sie dies nicht kontrollieren können, sollten Sie für user: ... in Ihrer Compose-Datei die UID oder GID verwenden, die vom Autor des Bildes beabsichtigt wurde.

Wenn der Autor des Images die UID 0 verwendet hat und Sie den Dienst nicht als Root ausführen möchten (und er kann als unprivilegierter Benutzer ausgeführt werden), wenden Sie sich natürlich an den Docker-Image-Autor.

@Redsandro Überprüfen Sie die Docker und --userns-remap, wie werden Volume-Berechtigungen verwaltet, um Daten zwischen Host und Container zu teilen?

Da dies nicht von Docker verwaltet werden muss, können Sie einen anderen Container erstellen, um Ihre Volumes bereitzustellen, bevor die zugehörigen Container beginnen, z. B. mit 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"

Ich verstehe nicht, warum Docker dieses Problem nicht repariert, ich stimme zu, dass wir es für Entwicklungszwecke hacken können, aber in der Produktion auf keinen Fall!

IMHO podman kann als (unprivilegierter) Benutzer laufen (siehe auch hier ) und wird dies wahrscheinlich lösen. Jemand arbeitet auch an einer Compose-Lösung und die Podman-API ist in den meisten Teilen absichtlich kompatibel zu Docker.

[podman] könnte hier jedoch einigen Leuten helfen, da es in großen Teilen mit Docker kompatibel ist.

Stimme voll und ganz zu, leider funktioniert Podman nicht auf dem Mac

Stimme voll und ganz zu, leider funktioniert Podman nicht auf dem Mac

Ich bin kein OS/X-Benutzer mehr, aber ich habe gerade gesehen, dass es einen _experimentellen_ podman dmg gibt .

Ich vermute, dass sich in naher Zukunft ein ähnliches Ökosystem entwickeln könnte, da es bereits möglich ist, auf podman programmatisch oder sogar auf podman-compose zuzugreifen .

Dies wird insbesondere dann zu einem Problem, wenn Benutzer ohne Sudo-Rechte auf einem freigegebenen Cluster versehentlich einige Ordner erstellen, die Root über docker-compose gehören, und diese Ordner dann nicht einmal selbst löschen können.

Ich bin auch auf dieses Problem gestoßen. Wir versuchen, docker in jpetazzos Beitrag beschrieben .

Wir möchten diesen Container aus der docker-compose-Datei starten und in der Lage sein, den Docker-Socket vom Host-Computer in den Container-Computer unter der Docker-Gruppe zu mounten. Dies ist so, dass wir einen anderen Benutzer als root verwenden können, um Docker aus dem Container heraus auszuführen.

Da ich den Besitz und die Berechtigung von Bind-Mount-Dateien nicht angeben kann, ist dies derzeit nicht möglich.

Geben Sie hier meine zwei Cent ein:

Für eine "native" Docker-Compose-Lösung habe ich dies getan, da die meisten Leute alpine bereits in ihrer Bildbibliothek haben:

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"

Natürlich nicht die sicherste Methode, aber nur Container, denen Berechtigungen für den Container gewährt werden, werden es sehen, also ist es keine große Sache, aber Sie könnten es leicht zu chown user:user machen oder etwas Setacl-Fantasie machen, wenn Ihr Kernel unterstützt es.

BEARBEITEN: Anscheinend müssen Sie den Ordner zuerst vor chmod chown oder er "klebt" nicht, zumindest in meinen Tests.

Der Besitz von Volumes unterliegt nicht der Kontrolle von docker-compose, daher sollte diese Diskussion unter Moby Project Repo stattfinden.

Einige Hinweise für Leute, die hier nach einer Problemumgehung suchen:
Docker-Volume erhält bei der ersten Verwendung durch einen Container den ursprünglichen Inhalt und die Berechtigung, die vom Container geerbt wurden. Das heißt, Sie können Ihr Bild wie folgt konfigurieren:

#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

Wenn ein solches Image ohne ein explizites Volume (das absichtlich mit einer zufälligen ID erstellt wird) oder mit einem benannten Volume, das noch nicht existiert, ausgeführt wird, "verbreitet" es Berechtigungen für das 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 ..

Das gleiche gilt, wenn Sie Volumes verwenden, die in einer Compose-Datei deklariert sind:

#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

Dies funktioniert nicht, wenn Sie ein Volume erneut anhängen, das bereits von einem anderen Container verwendet wurde. Das Ändern des Volume-Eigentümers oder dessen Kontrolle zum Zeitpunkt der Erstellung muss von der Engine oder von Volume-Treibern mit einigen spezifischen Optionen implementiert werden. Andernfalls müssen Sie sich wie vorgeschlagen auf einige chown Tricks verlassen ^.

Hoffe das hilft.
Ich schließe dieses Problem, da Compose keine Kontrolle über die Volume-Erstellung hat, sondern die verfügbare Engine-API.