Einführung
Die Berichtsanwendung hat bereits schreibgeschützte Konfiguration, läuft aber noch als root. Als Wartungsperson wählst du den vorbereiteten Anwendungsbenutzer und erhältst die echte Dokumenterstellung.
Diese unabhängige Umgebung enthält einen eigenen Berichtscontainer samt Daten. Du prüfst UID und Ausgabeeigentümer, bearbeitest das bekannte Startformat und erstellst und testest den Dienst neu. Bearbeite zuerst Das eingebundene Konfigurationsverzeichnis schützen.
Den Anwendungsbenutzer kennenlernen
In diesem Schritt prüfst du normales Dienstverhalten und unterscheidest Wartungsbenutzer und Containerprozessbenutzer. Die neue Umgebung hat bereits einen schreibgeschützten Konfigurations-Mount, doch der Dienst läuft noch als root.
Verwende Maintenance, das in /home/labex/project/report-desk startet. Dieses Terminal verwaltet nur den vorbereiteten Container report-renderer. Kehre bei Bedarf mit cd /home/labex/project/report-desk zurück. sudo docker exec lässt Docker einen Befehl im Ziel ausführen. id zeigt die numerische Benutzerkennung (UID) und Gruppenkennung (GID):
sudo docker exec report-renderer id
uid=0(root) gid=0(root) groups=0(root)
UID 0 ist root in diesem Container und hat mehr Rechte auf erreichbare Dateien als die Berichtsanwendung benötigt. Container-root administriert keine separate VM; Container teilen den Host-Kernel. Die Übung reduziert Dateizugriffe der Anwendung, nicht jedes mögliche Containerrisiko.
Die vorbereitete Identität ist UID/GID 1200:1200. Numerische Kennungen funktionieren ohne benanntes Konto im Image. Der Eigentümer des Host-Verzeichnisses muss diesem Benutzer das Schreiben ermöglichen. ls -ldn zeigt das Verzeichnis selbst (-d), ausführliche Rechte (-l) und numerische Kennungen (-n):
ls -ldn output
Suche drwxr-xr-x sowie Eigentümer/Gruppe 1200 1200. Der Eigentümer hat rwx: Lesen, Schreiben und Verzeichnisdurchlauf. Andere haben r-x: Lesen und Durchlauf, aber kein Schreiben. Das Verzeichnis wurde für diese Identität vorbereitet.
Erzeuge mit der bekannten POST-Anfrage ein Ausgangsdokument. curl -fsS meldet HTTP-Fehler und -X POST fordert die Geschäftsaktion an:
curl -fsS -X POST http://localhost:8090/render/baseline
{"saved": "/output/baseline.json", "total": 37, "uid": 0}
Der Bericht funktioniert, wurde aber von UID 0 erzeugt. Öffne Document Desk, um das gespeicherte Dokument zu sehen; die Seite listet echte Ausgabedateien.
Die vorbereitete Identität wählen
In diesem Schritt änderst du die Anwendungsidentität in der Startdeklaration und erhältst den nötigen Dateisystemzugriff. cat zeigt das Skript:
cat launch.sh
sudo autorisiert die Host-Verwaltung. Unabhängig davon bestimmt --user Benutzer und Gruppe der Containeranwendung. 0:0 bedeutet UID 0 und GID 0. 1200:1200 wählt die vorbereitete Identität. Behalte Port 8090, das vorbereitete Image und beide Mount-Pfade. Die Konfigurationszeile enthält bereits dst=/config,readonly; die Ausgabe muss beschreibbar bleiben.
Öffne den Terminaleditor:
nano launch.sh
Ersetze mit den Pfeiltasten nur --user 0:0 durch --user 1200:1200. Speichere mit Ctrl+O, Enter und beende mit Ctrl+X. Zeige die Datei erneut:
cat launch.sh
Die Benutzerzeile sollte lauten:
--user 1200:1200 \
Eine geänderte Deklaration aktualisiert den laufenden Prozess nicht. Lege vor dem Neuerstellen den vorgesehenen Eigentümer des Ausgabeverzeichnisses ausdrücklich fest. chown setzt numerischen Eigentümer und Gruppe; sudo ist nötig, weil diese Kennungen vom Host-Wartungsbenutzer abweichen. Das betrifft nur das Verzeichnis, nicht alle darin vorhandenen Dateien:
sudo chown 1200:1200 output
Mache nicht alles schreibgeschützt: Dokumenterstellung benötigt Ausgabe-Schreibzugriff. Gib auch nicht allen Schreibrechte, um Eigentumsprobleme zu umgehen; der vorbereitete Eigentümer kann mit den vorhandenen Verzeichnisrechten 755 schreiben.
Neu erstellen und das Geschäftsergebnis erhalten
In diesem Schritt wendest du die neue Identität an und testest normale Ausgabe sowie geschützte Eingaben. Entferne wie zuvor nur den Zielcontainer und starte seinen Ersatz:
sudo docker rm -f report-renderer
bash launch.sh
Falls der Start fehlschlägt, korrigiere launch.sh mit nano, entferne das fehlerhafte Ziel mit demselben Löschbefehl und starte das Skript erneut. Die Host-Daten bleiben erhalten. Prüfe die laufende Identität:
sudo docker exec report-renderer id
uid=1200 gid=1200 groups=1200
Warte kurz auf den Start und erzeuge das endgültige Dokument:
curl -fsS -X POST http://localhost:8090/render/final
{"saved": "/output/final.json", "total": 37, "uid": 1200}
Permission denied deutet meist auf einen falschen Verzeichniseigentümer oder eine früher von root erstellte final.json hin. Korrigiere das Verzeichnis mit sudo chown 1200:1200 output. Falls eine alte finale Datei existiert, löscht sudo rm output/final.json nur dieses erzeugte Dokument; fordere es erneut an. Read-only file system für /output bedeutet einen versehentlich gesperrten Ausgabe-Mount: Korrigiere die Deklaration und erstelle den Container neu.
Prüfe die erzeugte Datei. ls -ln zeigt numerische Eigentümer, cat den Inhalt:
ls -ln output/final.json
cat output/final.json
Suche Eigentümer 1200, "uid": 1200, Summe 37 und Report for Harbor Books: 37 orders. Aktualisiere Document Desk, um die Datei zu sehen. Bestätige abschließend den erhaltenen Konfigurationsschutz:
sudo docker exec report-renderer touch /config/probe.txt
touch: /config/probe.txt: Read-only file system
Dieser Fehler ist erwartet. Nicht-root-Identität und schreibgeschützter Mount lösen verschiedene Probleme: Die UID-Auswahl reduziert Prozessrechte, während der Mount-Modus Konfigurationsschreiben selbst durch Container-root verhindert. Der Dienst erfüllt weiterhin seine eigentliche Aufgabe.
Zusammenfassung
Du hast Host-Wartungszugriff und Anwendungsidentität getrennt, UID/GID 1200 gewählt und das Ausgabeverzeichnis erhalten. Der laufende Prozess und das neue Dokument verwenden jetzt UID 1200, während Konfigurationsschreibzugriffe weiterhin scheitern.
