User Namespaces gehören zu den einflussreichsten, aber oft wenig intuitiven Funktionen des Linux-Kernels. Sie ermöglichen, Benutzer-IDs innerhalb eines Containers anders abzubilden als auf dem Host. Dieser Mapping-Mechanismus bildet das Fundament des rootlosen Containerbetriebs. Ohne ihn wäre Podman im rootlosen Modus nicht funktionsfähig.
Der zentrale Effekt: Prozesse können im Container als „root“ auftreten, ohne auf dem Host tatsächliche Privilegien zu besitzen.
Ein Containerprozess kann innerhalb seines Namespaces mit UID 0 laufen, während derselbe Prozess auf dem Host lediglich als gewöhnlicher Benutzer existiert. Der Kernel übernimmt die Übersetzung von IDs zwischen beiden Bereichen.
Schematische Darstellung:
Das Mapping basiert auf den Einträgen in /etc/subuid und
/etc/subgid. Diese definieren ID-Bereiche, die ein Benutzer
für rootlosen Betrieb verwenden darf.
Dadurch entsteht eine konstruktive Illusion: Der Prozess besitzt im Container volle Rechte, aber auf dem Host keinerlei Privileg.
Viele Programme setzen voraus, dass sie als root laufen, weil sie:
Solche Programme würden als normaler Benutzer im Container nicht funktionieren. Der User Namespace löst dieses Problem elegant: Im Container entsteht eine Umgebung, die root-semantisch ist, ohne auf dem Host root zu benötigen.
Kurz gesagt:
Kompatibilität im Container, Sicherheit auf dem Host.
Podman liest beim Start die Sub-UID- und Sub-GID-Ranges des Benutzers ein – typischerweise 65.536 IDs.
Beispiel aus /etc/subuid:
username:100000:65536Bedeutung:
Vor dem Start konfiguriert die Engine dieses Mapping im User Namespace. Die OCI-Runtime nutzt die fertig eingerichtete Umgebung und der Kernel übernimmt die Übersetzung automatisch.
Erzeugt ein Container mit UID 0 eine Datei in einem Bind-Mount, erscheint diese Datei auf dem Host nicht als root, sondern mit der gemappten UID:
-rw-r--r-- 1 100000 100000 42 output.binDiese Datei gehört dem „root“ im Container, aber dem nicht privilegierten Mapping-Benutzer auf dem Host.
Ein praktischer Merksatz:
Hohe numerische UIDs in Bind-Mounts sind fast immer ein Hinweis auf User Namespace Mapping.
Podman kann solche Situationen durch shifted Overlayfs teilweise automatisieren, dennoch ist das Verständnis des Grundprinzips wichtig.
User Namespaces begrenzen den möglichen Schaden eines Container-Ausbruchs erheblich:
Der Mechanismus bildet daher eine zentrale Sicherheitsschicht im rootlosen Betrieb.
Einige Host-Ressourcen – insbesondere Geräte – sind nicht automatisch mit User Namespaces kompatibel. Der Host muss Geräte explizit für unprivilegierte Prozesse freigeben:
/devPodman kann nur auf jene Geräte zugreifen, die der Kernel für den gemappten Benutzerbereich sichtbar macht.
Zur Kontrolle der ID-Situation innerhalb und außerhalb des Containers:
Container-Sicht:
podman run --rm alpine idHost-Sicht:
ls -ln /pfad/zum/mountDie Differenz der IDs zeigt das aktuelle Mapping.
User Namespace Mapping ist einer der tragenden Pfeiler des rootlosen Containerbetriebs. Er erlaubt Abläufe, die root erfordern, ohne echte Rootrechte auf dem Host zu vergeben. Der Mechanismus schafft Sicherheit, ohne den Funktionsumfang im Container einzuschränken, und bildet damit einen wesentlichen Teil der Architektur, die Podman von klassischen daemonbasierten Engines unterscheidet.