BEZEICHNUNG¶

systemd-nsresourced.service, systemd-nsresourced - Benutzernamensraum-Ressourcendelegationsdienst

ÜBERSICHT¶

systemd-nsresourced.service

/usr/lib/systemd/systemd-nsresourced

BESCHREIBUNG¶

systemd-nsresourced ist ein Systemdienst, der die flüchtige Delegation eines UID/GID-Bereichs an einen, durch einen Client reservierten Benutzernamensraum (siehe user_namespaces(7)) mittels einer Varlink-IPC-API erlaubt.

Nicht privilegierte Clients können einen Benutzernamensraum reservieren und dann mittels dieses Dienstes die Zuweisung eines UID/GID-Bereichs anfordern. Der Benutzernamensraum kann dann zur Ausführung von Containern und anderen Sandboxes verwandt werden und/oder auf eine Einhängung mit zugeordneter Kennung angewandt werden.

Reservierungen von UIDs/GIDs auf diese Art sind flüchtig: wenn ein Benutzernamensraum verschwindet, wird sein UID/GID-Bereich wieder zum Fundus der verfügbaren Bereiche hinzugefügt. Damit Clients keine Beständigkeit in ihren flüchtigen UID/GID-Bereichen erlangen, wird eine BPF-LSM-basierte Richtlinie durchgesetzt, die sicherstellt, dass auf diese Weise eingerichtete Benutzernamensräume nur in Dateisysteme schreiben können, die sie selbst reserviert haben oder die explizit mittels systemd-nsresourced als erlaubt gelistet sind.

systemd-nsresourced stellt automatisch sicher, dass alle registrierten UID-Bereiche in der NSS-Datenbank des Systems mittels Benutzer-/Gruppen-Datensatznachschlage-API über Varlink[1] erscheinen.

Derzeit können nur UID/GID-Bereiche, die aus genau einer oder genau 65536 UIDs/GIDs bestehen, mit diesem Dienst registriert werden. Desweiteren werden UIDs und GIDs immer zusammen und symmetrisch registriert.

Das Reservierungs-API (»allocation API«) unterstützt delegierte Bereiche: zusätzliche UID/GID-Bereiche, die 1:1 in den Benutzernamensraum abgebildet werden, statt zu einer Ziel-UID/GID übersetzt zu werden. Diese delegierten Bereiche ermöglichen verschachtelte Namensraumszenarien, bei denen ein Container Kind-Benutzernamensräume mit seinen eigenen flüchtigen UID-Bereichen erstellen muss. Normalerweise beschränkt der Kernel, welche UIDs in einen Benutzernamensraum abgebildet werden können auf solche, die auch im Elternnamensraum abgebildet sind. Delegierte Bereiche lösen dies, indem vorab zusätzliche Bereiche reserviert werden, die im Benutzernamensraum sichtbar sind und in verschachtelten Aufrufen AllocateUserRange() verwandt werden können. Pro Benutzernamensraum können bis zu 16 delegierte Bereiche jeweils der Größe 65536 erbeten werden. Die Bereiche werden aus den Container-UID-Bereichen gemäß Benutzer, Gruppen, UIDs und GIDs auf Systemd-Systemen[2] reserviert.

Das Reservierungs-API unterstützt auch Identitätsabbildungen: Anstatt einen flüchtigen UID/GID-Bereich zu reservieren, kann der Benutzernamensraum zur Abbildung der UID/GID des Aufrufenden auf Root (UID 0) innerhalb des Namensraums oder sich selbst konfiguriert werden. Identitätsabbildungen können mit delegierten Bereichen kombiniert werden, um einen privilegierten Namensraum zu betreten, aus dem der Container eingerichtet werden kann, der dann anschließend in einem der delegierten Bereiche ausgeführt werden kann. Identitätsabgebildete Benutzer unterligen den BPF-LSM-Schreibbeschränkungen nicht, anders als flüchtige Bereiche.

Zusätzlich unterstützt das Reservierungs-API die Abbildung des fremden UID-Bereichs in den Benutzernamensraum. Wird diese Option aktiviert, wird der fremde UID-Bereich 1:1 in den Benutzernamensraum abgebildet. Dies erlaubt Prozessen innerhalb den Zugriff auf und die Veränderung von Dateien, die dem fremden UID-Bereich gehören.

Der Dienst stellt API-Aufrufe bereit, um Einhängungen (die mittels ihrer Einhängedateideskriptoren gemäß des fsmount()-API von Linux referenziert sind), die als erlaubt aufgelistet sind, die Eigentümerschaft eines Cgroup-Unterbaums an den Benutzernamensraum weiterzugeben und ein virtuelles Ethernet-Gerätepaar an den Benutzernamensraum zu delegieren. Wird dies zusammen benutzt, reicht dies aus, um vollständig unprivilegierte Container-Umgebungen, wie dies von systemd-nspawn(1) implementiert wird, vollständig unprivilegierte RootImage= (siehe systemd.exec(5)) oder vollständig unprivilegierte Plattenabbildwerkzeuge wie systemd-dissect(1) zu implementieren.

Dieser Dienst stellt einen Varlink[3]-Dienst bereit: io.systemd.NamespaceResource erlaubt die Registrierung von Benutzernamensräumen und weist ihnen Einhängungen, Cgroups und Netzwerkschnittstellen zu.

SIEHE AUCH¶

systemd(1), systemd-mountfsd.service(8), systemd-nspawn(1), systemd.exec(5), systemd-dissect(1), user_namespaces(7)

ANMERKUNGEN¶

1.

Benutzer-/Gruppen-Datensatznachschlage-API über Varlink

2.

Benutzer, Gruppen, UIDs und GIDs auf Systemd-Systemen

3.

Varlink

ÜBERSETZUNG¶

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org.