Worum geht es?

Es handelt sich um ein eher technisches Problem bei der Verwendung von Docker-Containern, die mit dem Docker-Hostcomputer interagieren, im Allgemeinen im Zusammenhang mit der Verwendung des Host-Dateisystems innerhalb des Containers.
Dies geschieht insbesondere im reproduzierbaren Forschungskontext.
Ich habe ein Open-Source-Dienstprogramm entwickelt, das bei der Lösung dieses Problems hilft.

Docker-Container als Ausführungsumgebungen

Der anfängliche und Hauptanwendungsfall eines Docker-Containers: eine eigenständige Anwendung, die nur über einige Netzwerkports mit dem Hostsystem interagiert.
Stellen Sie sich eine Webanwendung vor: Der Docker-Container enthält normalerweise einen Webserver und eine Webanwendung, die beispielsweise auf Port 80 (im Container) ausgeführt wird. Der Container wird dann auf dem Host ausgeführt, indem der interne Container-Port 80 an einen Host-Port (z. B. 8000) gebunden wird.
Dann erfolgt die einzige Interaktion zwischen der Container-App und dem Hostsystem über diesen gebundenen Netzwerkport.

Container als Ausführungsumgebungen sind völlig unterschiedlich:

• Anstatt eine Anwendung zu containerisieren, wird das Anwendungserstellungssystem containerisiert.
  • Es könnte ein Compiler, eine IDE, eine Notebook-Engine, ein Quarto-Publishing-System sein...
• Die Ziele sind:
  • um eine standardmäßige Umgebung zu haben, die einfach zu installieren und zu teilen ist
    • Stellen Sie sich eine komplexe Build-Umgebung mit festen Versionen von R, Python und Millionen externer Pakete vor. Alles mit den richtigen Versionen zu installieren, kann eine sehr schwierige und zeitaufwändige Aufgabe sein. Durch das Teilen eines Docker-Images, das alles enthält, was bereits installiert und vorkonfiguriert ist, können Sie wirklich Zeit sparen.
  • um eine reproduzierbare Umgebung zu haben
    • Durch die Verwendung können Sie einige Analyseergebnisse reproduzieren, da Sie dieselbe kontrollierte Umgebung verwenden
    • Sie können Fehler auch einfach reproduzieren, was der erste Schritt zu deren Behebung ist

Um diese Ausführungsumgebungen nutzen zu können, müssen diese Container jedoch Zugriff auf das Hostsystem haben, insbesondere auf das Host-Benutzerdateisystem.

Docker-Container und das Host-Dateisystem

Angenommen, Sie haben eine IDE containerisiert, z. Rstudio.
Ihr Rstudio ist im Docker-Container installiert und wird ausgeführt, muss jedoch Dateien in Ihrem Projektordner lesen und bearbeiten.

Dafür binden Sie das Mounten Ihres Projektordners (in Ihrem Host-Dateisystem) mithilfe der Docker-Run-Option --volume.
Dann sind Ihre Dateien über den Docker-Container zugänglich.

Die Herausforderung sind nun die Dateiberechtigungen. Angenommen, Ihr Host-Benutzer hat die Benutzer-ID 1001 und der Benutzer, der den Rsudio-Prozess im Container besitzt, ist entweder 0 (Root) oder 1002.

Wenn der Containerbenutzer root ist, treten beim Lesen Ihrer Dateien keine Probleme auf.
Sobald Sie jedoch einige vorhandene Dateien bearbeiten oder neue erstellen (z. B. PDF, HTML), gehören diese Dateien zum Root auch im Host-Dateisystem!.
Das bedeutet, dass Ihr lokaler Hostbenutzer sie nicht verwenden oder löschen kann, da sie zum Root gehören.

Wenn die Container-Benutzer-ID nun 1002 lautet, kann Rstudio Ihre Dateien möglicherweise nicht lesen, bearbeiten oder neue Dateien erstellen.
Auch wenn dies möglich ist, kann Ihr lokaler Hostbenutzer aufgrund der Einstellung einiger sehr freizügiger Berechtigungen diese möglicherweise nicht verwenden.

Natürlich besteht eine Brute-Force-Methode zur Lösung dieses Problems darin, sowohl auf dem Host-Computer als auch im Docker-Container mit Root ausgeführt zu werden. Dies ist nicht immer möglich und wirft einige offensichtliche kritische Sicherheitsbedenken auf.

Lösung des Dateieigentümerproblems Teil 1: die Docker-Option run --user

Da wir nicht im Voraus wissen können, wie die Host-Benutzer-ID lautet (hier 1001), können wir nicht vorkonfigurieren
die Benutzer-ID des Docker-Container-Benutzers.

docker run bietet jetzt eine Option --user, die es ermöglicht, einen Pseudobenutzer mit einer angegebenen Benutzer-ID zu erstellen
zur Laufzeit. Beispielsweise erstellt docker run --user 1001 ... einen Docker-Container, der mit Prozessen ausgeführt wird
gehört einem Benutzer mit der Benutzer-ID 1001.

Was diskutieren wir also noch über dieses Thema? Ist es nicht gelöst?

Hier einige Besonderheiten zu diesem dynamisch erstellten Benutzer:

• es ist ein Pseudobenutzer
• es hat kein Home-Verzeichnis (/home/xxx)
• es erscheint nicht in /etc/passwd
• es kann nicht vorkonfiguriert werden, z.B. mit einem Bash-Profil, einigen Umgebungsvariablen, Anwendungsstandards usw.

Wir können diese Probleme umgehen, aber es kann mühsam und frustrierend sein.
Was wir wirklich gerne hätten, wäre, einen Docker-Container-Benutzer vorzukonfigurieren und seine Benutzer-ID zur Laufzeit dynamisch ändern zu können...

Lösung des Dateieigentümerproblems Teil 2: Geben Sie docker_userid_fixer ein

docker_userid_fixer ist ein Open-Source-Dienstprogramm, das als Docker-Einstiegspunkt verwendet werden soll, um das gerade angesprochene Benutzer-ID-Problem zu beheben.

Sehen wir uns an, wie man es verwendet: Sie legen es als Ihren Docker-ENTRYPOINT fest, geben an, welcher Benutzer verwendet werden soll, und lassen seine Benutzer-ID dynamisch ändern:

ENTRYPOINT ["/usr/local/bin/docker_userid_fixer","user1"]

Seien wir präziser:

• der Zielbenutzer ist der Benutzer, der für docker_userid_fixer angefordert wird, hier Benutzer1
• Der angeforderte Benutzer ist der von Docker Run bereitgestellte Benutzer, d. h. der Benutzer, der (zunächst) Eigentümer des ersten Prozesses (PID 1) ist

Dann gibt es bei der Container-Laufzeiterstellung zwei Optionen:

• Entweder stimmt die angefragte-Benutzer-ID (bereits) mit der Ziel-Benutzer-ID überein, dann muss nichts geändert werden
• oder nicht. Beispielsweise ist die Benutzer-ID angefordert 1001 und die Benutzer-ID Ziel ist 100. Anschließend korrigiert docker_userid_fixer die Benutzer-ID des Zielbenutzers Benutzers Benutzer1 von 1000 auf 1001 direkt im Container-Hauptprozess.

In der Praxis löst dies also unser Problem:

• Wenn Sie Ihre Container-Benutzer-ID nicht korrigieren müssen, verwenden Sie einfach Docker Run auf die übliche Weise (ohne die Option --user)
• oder Sie verwenden die Option --user, dann wird zusätzlich zur Ausführung Ihres Hauptprozesses mit einer von Ihnen angeforderten Benutzer-ID Ihr vorkonfigurierter Benutzer in Ihre angeforderte Benutzer-ID geändert, sodass Ihr Container mit Ihrem beabsichtigten und beabsichtigten Benutzer ausgeführt wird Benutzer-ID.

docker_userid_fixer-Setup

Anweisungen zur Einrichtung finden Sie hier.

Aber es läuft darauf hinaus:

• Erstellen oder laden Sie die kleine ausführbare Datei herunter (17 KB)

• kopieren Sie es in Ihr Docker-Image

• als Setuid-Root ausführbar machen

• konfigurieren Sie es als Ihren Einstiegspunkt

die blutigen Details

Ich habe einige kurze Notizen gemacht https://github.com/kforner/docker_userid_fixer#how-it-works
aber ich werde versuchen, es umzuformulieren.

Der Kern der Implementierung ist das Setuid-Stammverzeichnis der ausführbaren Datei docker_userid_fixer im Container.
Wir benötigen Root-Berechtigungen, um die Benutzer-ID zu ändern, und diese Setuid ermöglicht diese privilegierte Ausführung nur für
das docker_userid_fixerprogram, und das nur für sehr kurze Zeit.

Sobald die Benutzer-ID bei Bedarf geändert wurde, wechselt docker_userid_fixer den Hauptprozess
an den angeforderten Benutzer (und die Benutzer-ID!) senden.

Wenn Sie an diesen Themen interessiert sind (Docker, reproduzierbare Forschung, R-Paketentwicklung, Algorithmen, Leistungsoptimierung, Parallelität...), zögern Sie nicht, mich zu kontaktieren, um Job- und Geschäftsmöglichkeiten zu besprechen.