Zwei Optionen, die ich gefunden habe:
CHOWN all die Dinge (nachdem Sie Ihre Arbeit erledigt haben)
Ich habe docker run -v `pwd`/shared:/shared image gemacht , und der Container hat Dateien innerhalb von pwd/shared erstellt so gehört der Docker-Prozess. Jedoch /shared ist immer noch in meinem Besitz. Innerhalb des Docker-Prozesses tue ich das also
chown -R `stat -c "%u:%g" /shared` /shared
stat -c "%u:%g" /shared gibt 1000:1000 zurück in meinem Fall der uid:gid meines Benutzers. Obwohl es keinen Benutzer 1000 gibt Innerhalb des Docker-Containers ist die ID vorhanden (und stat /shared sagt nur "unbekannt", wenn Sie nach dem Benutzernamen fragen).
Wie auch immer, chown überträgt gehorsam das Eigentum an den Inhalten von /shared bis 1000:1000 (was meiner Meinung nach nicht existiert, aber außerhalb des Containers bin ich es). Also besitze ich jetzt alle Dateien. Der Container kann immer noch Dinge ändern, wenn er möchte, weil es aus seiner Sicht root ist .
Und alles ist gut mit der Welt.
docker run -u so haben alle erstellten Dateien automatisch den richtigen Besitzer
Eine andere Möglichkeit, dies zu tun, ist der -u flag on docker run.
docker run -v `pwd`/shared:/shared -u `stat -c "%u:%g" /shared` ubuntu bash
Auf diese Weise ist der Docker-Benutzer im Container youruid:yourgid .
Allerdings: das bedeutet, dass Sie Ihre Root-Berechtigung innerhalb des Containers aufgeben (apt-get install , etc.). Es sei denn, Sie erstellen einen Benutzer mit dieser neuen UID und fügen sie zu root hinzu Gruppe.
Ist das korrekt? Kann mir jemand eine Dokumentation dazu zeigen, ich vermute nur basierend auf dem obigen Experiment.
Vielleicht liegt das nur daran, dass beide denselben numerischen Wert im Kernel haben, und wenn ich auf einem System getestet habe, auf dem mein Heimbenutzer nicht die ID 1000 hatte, würden die Berechtigungen in jedem Fall geändert?
Lesen Sie info coreutils 'chown invocation' , das könnte Ihnen eine bessere Vorstellung davon geben, wie Dateiberechtigungen/Eigentum funktionieren.
Grundsätzlich ist jedoch jede Datei auf Ihrem Computer mit einer Reihe von Bits versehen, die ihre Berechtigungen und ihren Besitz definieren. Wenn Sie chown eine Datei, setzen Sie nur diese Bits.
Wenn Sie chown eine Datei an einen bestimmten Benutzer/eine bestimmte Gruppe unter Verwendung des Benutzernamens oder Gruppennamens, chown sucht in /etc/passwd für den Benutzernamen und /etc/group damit die Gruppe versucht, den Namen einer ID zuzuordnen. Wenn der Benutzername/Gruppenname in diesen Dateien nicht vorhanden ist, chown wird fehlschlagen.
[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'
Sie können jedoch chown eine Datei, die IDs verwendet, was immer Sie wollen (innerhalb einiger oberer positiver ganzzahliger Grenzen natürlich), unabhängig davon, ob es einen Benutzer / eine Gruppe gibt, die mit diesen IDs auf Ihrem Computer existiert oder nicht.
[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
Die UID- und GID-Bits werden in der Datei selbst gesetzt. Wenn Sie also diese Dateien in Ihrem Docker-Container mounten, hat die Datei dieselbe Eigentümer-/Gruppen-UID wie auf dem Host, ist aber jetzt /etc/passwd im Container, der wahrscheinlich ein anderer Benutzer sein wird, es sei denn, er gehört root (UID 0).
Die eigentliche Frage ist natürlich:"Was mache ich dagegen?" Wenn bob auf dem angegebenen Host-Rechner als bob angemeldet ist, sollte er in der Lage sein, den Container als bob auszuführen und keine Dateiberechtigungen unter seinem Host-Konto zu ändern. So wie es aussieht, muss er den Container tatsächlich als Docker-Benutzer ausführen, um zu vermeiden, dass sein Konto geändert wird.
Es scheint, als müssten Sie bei Ihrer aktuellen Einrichtung sicherstellen, dass Ihre UIDs> Benutzernamen in /etc/passwd sind auf Ihrem Host mit Ihren UIDs> Benutzernamen in Ihren Containern übereinstimmen /etc/passwd wenn Sie mit Ihrem gemounteten Benutzerverzeichnis als derselbe Benutzer interagieren möchten, der auf dem Host angemeldet ist.
Sie können einen Benutzer mit einer bestimmten Benutzer-ID mit useradd -u xxxx erstellen . Buuuut, das scheint eine ziemlich unordentliche Lösung zu sein...
Möglicherweise müssen Sie sich eine Lösung einfallen lassen, die das Home-Verzeichnis eines Host-Benutzers nicht einbindet.
Also endete ich in diesem Beitrag damit, wie man das Eigentum an allen Dateien (im Besitz von root) wiederherstellt, die aus einem Docker-Container stammen, der als root ausgeführt wird , an meinen nicht privilegierten Benutzer im Host.
Ich brauchte den Prozess innerhalb des Containers, um als Root ausgeführt zu werden, also kann ich -u nicht für die Docker-Ausführung verwenden.
Ich bin nicht stolz auf das, was ich getan habe, aber am Ende meines Bash-Skripts habe ich Folgendes hinzugefügt:
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/'
Lassen Sie uns einige der Zeilen aufschlüsseln:
- Führen Sie /bin/sh im Container aus:
--entrypoint /bin/sh
- Übergeben Sie die uid des aktuellen Benutzers als Umgebungsvariable an den Container:
-e HOST_UID=`id -u`
- Mounten Sie jeden Ordner, den Sie wieder besitzen möchten, wieder für Ihren Benutzer (gefüllt mit Dateien, die Root gehören, ausgegeben vom vorherigen Container, der als Root lief ), unter
/tmpdieses neuen Containers :
-v ${HOST_FOLDER_OWNED_BY_ROOT}:/tmp
- Führen Sie
chownaus rekursiv mit der UID des Hostbenutzers über das Zielverzeichnis (gemountet innerhalb des Containers in/tmp). ):
-c 'chown -R ${HOST_UID}:${HOST_UID} /tmp/'
Damit habe ich die Dateien, die meinem aktuellen Benutzer gehören, zurückbekommen, ohne dass ich die Berechtigungen auf root oder sudo „eskalieren“ musste.
Es ist schmutzig, aber es hat funktioniert. Hoffe, ich konnte helfen.