Warum beginnt ein Container erst nach einem Image-Update mit dem Erstellen von Dateien im Besitz von Root?

Ein Container kann nach einer Image-Aktualisierung Dateien im Besitz von root erstellen, wenn das neue Image seinen Laufzeitbenutzer, Entry-Point oder die Routine zur Besitzzuweisung beim Start ändert.

Das persistente Volume kann unverändert bleiben, während der Ersatzcontainer unter einer anderen numerischen UID startet oder kurzzeitig einen Initialisierungsschritt als root ausführt. Ein neuer Entry-Point kann fehlende Verzeichnisse erstellen, die Konfiguration migrieren, Berechtigungen neu schreiben oder die vom vorherigen Release verwendeten PUID- und PGID-Variablen nicht mehr berücksichtigen. Vergleichen Sie eine Datei vor der Aktualisierung, eine beim Start erstellte Datei und eine von der laufenden Anwendung erstellte Datei, bevor Sie Besitzänderungen rekursiv anwenden.

Beweisen Sie, dass sich der Besitz erst nach dem Start des aktualisierten Containers ändert

Stoppen Sie den Stack und dokumentieren Sie die numerische UID, GID, den Modus, ACLs und Zeitstempel einer vorhandenen Datei sowie ihres übergeordneten Verzeichnisses. Starten Sie den aktualisierten Container einmal mit sichtbaren Logs und prüfen Sie anschließend denselben Pfad sowie eine neu erstellte Datei.

Die Linux-chown-Systemaufrufe ändern den numerischen Besitz. Entscheidend sind daher die UID und GID vor und nach dem Start, nicht der vom Host angezeigte Benutzername.

Wenn der Besitz bereits vor dem Start bei root liegt, ist die Aktualisierung nicht die ursprüngliche Ursache. Untersuchen Sie die Aktualisierungskopie, die Extraktion, die Wiederherstellung eines Backups oder den Administrationsbefehl, durch den die Dateien geschrieben wurden.

Vergleichen Sie den Image-Benutzer vor und nach der Aktualisierung

Prüfen Sie die Konfiguration des alten und neuen Images, den effektiven Container-Benutzer, den Entry-Point, den Befehl und die Versionshinweise. Dokumentieren Sie, ob das Image nun root, ein benanntes Konto oder eine andere numerische UID verwendet.

Docker dokumentiert, dass die USER-Anweisung die Laufzeitidentität festlegt – sowohl für nachfolgende Image-Anweisungen als auch für Entry-Point und Befehl des Containers, sofern keine Laufzeitüberschreibung diese ersetzt.

Ein Image kann denselben Anwendungsbenutzernamen beibehalten und dennoch seine numerische UID ändern. Vergleichen Sie die Zahlen in beiden Image-Versionen, da auf dem Host eingehängte Dateien den numerischen Besitz und nicht die Benutzerbezeichnung des Images speichern.

Prüfen Sie, ob der neue Entry-Point ein rekursives Chown ausführt

Durchsuchen Sie Start-Logs, Versionshinweise, Entry-Point-Skripte und Prozessspuren nach chown, Berechtigungsreparatur, PUID, PGID, Benutzermigration oder Verzeichnisinitialisierung. Testen Sie dies anhand eines kleinen Snapshots oder eines nicht dauerhaft verwendeten Volumes.

GNU Coreutils definiert rekursives chown als Umschreiben des Besitzes im ausgewählten Verzeichnisbaum. Dadurch kann ein korrektes vorhandenes Volume unmittelbar nach dem Start des neuen Images so wirken, als habe sich sein Besitz geändert.

Entfernen Sie die Reparatur beim Start nicht unüberlegt. Einige Images benötigen sie für neu erstellte Verzeichnisse. Bevorzugen Sie ein dokumentiertes Flag zum Überspringen, eine feste Anwendungs-UID oder – sofern vom Image unterstützt – einen enger gefassten Datenpfad.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Prüfen Sie Compose-Benutzerüberschreibungen sowie entfernte PUID- oder PGID-Variablen

Vergleichen Sie das bereitgestellte Compose-Modell vor und nach der Aktualisierung, einschließlich user:, Umgebungsvariablen, zusätzlichen Gruppen, Profilen, Überschreibungsdateien und den gespeicherten Einstellungen des Stack-Managers.

Kubernetes verwendet explizite numerische Laufzeit- und Volume-Identitäten. Das verdeutlicht dieselbe Containergrenze: Eine Laufzeitüberschreibung und eine Richtlinie für den Volume-Besitz sind getrennte Einstellungen, die aufeinander abgestimmt bleiben müssen.

Wenn das alte Image PUID- und PGID-Variablen übersetzt hat, das neue Release diese jedoch entfernt oder umbenannt hat, können die Variablen weiterhin vorhanden sein, ohne den Prozess noch zu steuern. Überprüfen Sie die tatsächlich laufende UID direkt.

Berücksichtigen Sie Rootless-Betrieb und die Zuordnung von Benutzer-Namespaces

Dokumentieren Sie, ob Docker mit Root-Rechten, rootless oder mit der Neuzuordnung von Benutzer-Namespaces ausgeführt wird. Vergleichen Sie die im Container sichtbare UID mit dem auf dem Host sichtbaren Besitzer desselben Inodes.

Red Hat erklärt, dass rootless Container untergeordnete UID- und GID-Bereiche verwenden. Daher erscheint root im Container nicht zwangsläufig als Host-UID 0, und eine Aktualisierung kann eine geänderte Zuordnung oder einen anderen Laufzeitmodus sichtbar machen.

Ändern Sie den Besitz eines rootless Volumes nicht rekursiv auf den Host-Benutzer root, ohne die Zuordnung zu verstehen. Dadurch können die Daten für die vorgesehene Containeridentität unzugänglich werden.

Prüfen Sie, ob ein Idmapped- oder Netzwerk-Mount den sichtbaren Besitzer ändert

Stellen Sie fest, ob die Anwendungsdaten auf einem lokalen Dateisystem, einem idmapped Mount, NFS, SMB, FUSE oder einer NAS-Freigabe liegen. Dokumentieren Sie die Mount-Optionen und vergleichen Sie den Besitz auf Server, Host und im Container.

Das Idmapped-Mount-Modell des Linux-Kernels trennt Dateisystembesitz und Mount-Besitz. Daher kann dieselbe Datei unter unterschiedlichen IDs erscheinen, ohne dass der Besitz aller Inodes physisch rekursiv geändert wurde.

Wenn sich nach der Aktualisierung nur der angezeigte Besitzer ändert, prüfen Sie, ob die Laufzeit nun einen anderen Namespace oder ein anderes Mount-Mapping verwendet. Reparieren Sie die Zuordnung, statt jeden Inode neu zu schreiben.

Stellen Sie eine stabile Laufzeitidentität wieder her und überprüfen Sie die nächste Aktualisierung

Sichern Sie die Metadaten des Besitzes, stoppen Sie die Anwendung, legen Sie die vorgesehene numerische UID und GID fest, korrigieren Sie nur die von der Anwendung verwendeten Pfade und stellen Sie sie mit einem festgelegten Image sowie dokumentierten Benutzereinstellungen erneut bereit.

Der ZimaSpace-Artikel über den Containerbesitz nach dem Kopieren von Anwendungsdaten behandelt Ursachen durch Kopieren und Migration; dieser Artikel konzentriert sich auf eine Änderung, die durch das Ersatz-Image eingeführt wurde.

Die Reparatur ist abgeschlossen, wenn Start, Anwendungsschreibvorgänge, Neuerstellung des Containers, Neustart des Hosts und eine kontrollierte Image-Aktualisierung Dateien unter der dokumentierten Identität erstellen – ohne weitreichende Ausnahmen bei den Berechtigungen.

Häufig gestellte Fragen

Beweist eine Datei im Besitz von root, dass der gesamte Container als root ausgeführt wird?

Nein. Ein Entry-Point kann kurzzeitig als root ausgeführt werden, um ein Volume zu initialisieren, und anschließend die Berechtigungen abgeben, bevor die Anwendung startet.

Sollte ich das gesamte Volume rekursiv mit chown ändern?

Nicht, bevor Sie die vorgesehene UID, gemeinsam genutzte Pfade, ACLs und die Namespace-Zuordnung ermittelt haben. Eine umfassende Änderung kann Datenbanken, gemeinsam genutzte Medien oder den Besitz rootless Container beschädigen.

Kann eine Image-Aktualisierung die Anwendungs-UID ändern?

Ja. Maintainer können den Benutzer des Images ändern, die Kontodatenbank neu erstellen, PUID- oder PGID-Einstellungen umbenennen oder eine Migration des Besitzes beim Start hinzufügen.