Checkliste zur Benutzer- und Gruppenzuordnung von Containern für NAS-Freigaben

Der sichere Ansatz besteht darin, eine Prüfung der Zuordnung numerischer Identitäten vom NAS-Export über den Host-Mount bis zum laufenden Containerprozess als Abfolge beobachtbarer Prüfpunkte zu behandeln, nicht als einzelnen Befehl.

Auf einem Linux-Container-Host mit SMB- oder NFS-basierten NAS-Freigaben besteht das praktische Risiko darin, dass ein Container einen NAS-gemounteten Pfad sehen kann, Lese- oder Schreibvorgänge jedoch mit Berechtigungsfehlern scheitern. Halten Sie die aktuelle Identität und den Wiederherstellungspunkt fest, beginnen Sie mit dem am wenigsten invasiven Unterscheidungstest, interpretieren Sie erfolgreiche und fehlgeschlagene Ergebnisse, bevor Sie eine weitere Variable ändern, und stoppen Sie, sobald der Speicher instabil wird oder die einzige wiederherstellbare Kopie offengelegt würde. Der folgende Ablauf endet erst, wenn die ursprüngliche Arbeitslast erfolgreich ausgeführt wird oder die Beweislage eine Eskalationsgrenze erreicht.

Die tatsächliche Identität des Containerprozesses ermitteln

Prüfen Sie die Dokumentation des Images, die Compose-Einstellung user, Umgebungsvariablen, das Verhalten des EntryPoints sowie UID, GID und ergänzende Gruppen des laufenden Anwendungsprozesses. Variablen namens PUID und PGID sind Konventionen bestimmter Images und keine universellen Docker-Funktionen. Stellen Sie daher sicher, dass dieses Image sie unterstützt.

Ein Fall aus der LinuxServer-Community zu Container-Berechtigungen mit PUID und PGID zeigt, dass scheinbar korrekte PUID- und PGID-Werte einen Bind-Mount dennoch unzugänglich lassen können. Nutzen Sie den Fall als Erinnerung daran, den laufenden Prozess und den Mount zu prüfen, nicht als Beleg dafür, dass jedes Image dieselbe Initialisierungslogik verwendet.

Halten Sie die numerischen Werte mit id im Container und auf dem Host fest. Stoppen Sie, wenn die Anwendung nur deshalb als Root ausgeführt wird, weil Berechtigungen zuvor fehlgeschlagen sind. Der Root-Zugriff verbirgt den Zuordnungsfehler und erhöht die Auswirkungen eines kompromittierten Dienstes.

Den Besitz vom NAS bis zum Host-Mount verfolgen

Prüfen Sie auf dem NAS den numerischen Besitzer, die Gruppe, den Modus, die ACL und die Standard-ACL des Zielverzeichnisses. Prüfen Sie auf dem Container-Host dieselben gemounteten Objekte und vergleichen Sie die numerischen Werte. Wenn sich die Namen unterscheiden, die Zahlen jedoch übereinstimmen, sind die Bezeichnungen lediglich kosmetisch. Wenn die Zahlen abweichen, ist der Autorisierungspfad tatsächlich ein anderer.

Beziehen Sie bei NFS die Exportoptionen, die NFS-Version, das ID-Mapping, Root-Squashing und die Identität des Client-Mounts ein. Beziehen Sie bei SMB die Mount-Zugangsdaten, die serverseitig zugeordnete Identität, die Darstellungsoptionen uid oder gid sowie die Frage ein, ob Unix-Erweiterungen oder eine ACL-Übersetzung verwendet werden.

Ändern Sie nicht gleichzeitig Server-ACLs und Client-Mount-Optionen. Der Prüfschritt ist erfolgreich, wenn eine Testdatei einen bekannten numerischen Besitzer hat und der Host nach dem Aushängen, erneuten Einhängen und einem Neustart eine stabile Zuordnung erkennt.

Den Bind-Mount und ergänzende Gruppen testen

Bestätigen Sie, dass der Quellpfad des Containers tatsächlich der erwartete Host-Mount ist und nicht ein leeres lokales Verzeichnis, das vor dem Einhängen der Netzwerkfreigabe erstellt wurde. Prüfen Sie den Laufzeit-Mount und testen Sie anschließend das Auflisten, Lesen, Erstellen, Umbenennen und Löschen als Anwendungsbenutzer in einem temporären Unterverzeichnis.

Ein Fall auf Server Fault dokumentiert eine Berechtigungsabweichung bei NFS-ACLs, obwohl Besitzer und ACL-Einträge scheinbar übereinstimmen. Das zeigt, warum ACL-Maske, Server-Zuordnung und effektive Identität sämtlich geprüft werden müssen. Erfassen Sie getfacl sowohl für das Verzeichnis als auch für die erstellte Datei.

Wenn Gruppenzugriff vorgesehen ist, fügen Sie die unterstützte ergänzende numerische Gruppe hinzu und erstellen Sie den Container neu, da Prozessgruppen beim Start festgelegt werden. Nutzen Sie den ZimaSpace-Leitfaden zur Diagnose leerer Containerpfade, wenn die Anwendung mit einem leeren Pfad startet. Das ist ein Mount-Reihenfolgeproblem und kein ACL-Problem.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Die engste Identitätskorrektur anwenden und erneut testen

Richten Sie die unterstützte UID, GID oder ergänzende Gruppe der Anwendung bevorzugt an der NAS-Richtlinie aus. Verwenden Sie eine gemeinsame Gruppe und vererbte ACLs, wenn mehrere Dienste zusammenarbeiten. Vermeiden Sie weltweit beschreibbare Berechtigungen, rekursive Besitzänderungen über nicht zusammengehörige Datensätze hinweg und privilegierte Container als Abkürzungen.

Erstellen Sie den Container neu, hängen Sie die Freigabe erneut ein, wenn sich Zuordnungsoptionen geändert haben, und wiederholen Sie dieselben Vorgänge. Starten Sie den Host einmal neu, um zu überprüfen, dass Mount-Reihenfolge und numerische Identität den Systemstart überstehen. Bestätigen Sie, dass neu erstellte Dateien für die vorgesehenen menschlichen Benutzer weiterhin beschreibbar bleiben, ohne dem Container unnötige Rechte zu geben.

Schließen Sie die Checkliste ab, wenn die Anwendung ihre ursprüngliche Arbeitslast erfolgreich ausführt, verweigerte Vorgänge weiterhin verweigert werden und der Besitz nach einem Neustart stabil bleibt. Eskalieren Sie, wenn User-Namespaces, Rootless-Zuordnungen oder NAS-Identitätsdienste IDs auf eine Weise umschreiben, die das ausgewählte Image nicht unterstützen kann.