SYSTEMD-NSRESOURCED.SERVICE(8) systemd-nsresourced.service BEZEICHNUNG systemd-nsresourced.service, systemd-nsresourced - Benutzernamensraum-Ressourcendelegationsdienst UBERSICHT systemd-nsresourced.service /usr/lib/systemd/systemd-nsresourced BESCHREIBUNG systemd-nsresourced ist ein Systemdienst, der die fluchtige 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 konnen einen Benutzernamensraum reservieren und dann mittels dieses Dienstes die Zuweisung eines UID/GID-Bereichs anfordern. Der Benutzernamensraum kann dann zur Ausfuhrung von Containern und anderen Sandboxes verwandt werden und/oder auf eine Einhangung mit zugeordneter Kennung angewandt werden. Reservierungen von UIDs/GIDs auf diese Art sind fluchtig: wenn ein Benutzernamensraum verschwindet, wird sein UID/GID-Bereich wieder zum Fundus der verfugbaren Bereiche hinzugefugt. Damit Clients keine Bestandigkeit in ihren fluchtigen UID/GID-Bereichen erlangen, wird eine BPF-LSM-basierte Richtlinie durchgesetzt, die sicherstellt, dass auf diese Weise eingerichtete Benutzernamensraume nur in Dateisysteme schreiben konnen, 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 uber Varlink[1] erscheinen. Derzeit konnen 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<<) unterstutzt delegierte Bereiche: zusatzliche UID/GID-Bereiche, die 1:1 in den Benutzernamensraum abgebildet werden, statt zu einer Ziel-UID/GID ubersetzt zu werden. Diese delegierten Bereiche ermoglichen verschachtelte Namensraumszenarien, bei denen ein Container Kind-Benutzernamensraume mit seinen eigenen fluchtigen UID-Bereichen erstellen muss. Normalerweise beschrankt der Kernel, welche UIDs in einen Benutzernamensraum abgebildet werden konnen auf solche, die auch im Elternnamensraum abgebildet sind. Delegierte Bereiche losen dies, indem vorab zusatzliche Bereiche reserviert werden, die im Benutzernamensraum sichtbar sind und in verschachtelten Aufrufen AllocateUserRange() verwandt werden konnen. Pro Benutzernamensraum konnen bis zu 16 delegierte Bereiche jeweils der Grosse 65536 erbeten werden. Die Bereiche werden aus den Container-UID-Bereichen gemass Benutzer, Gruppen, UIDs und GIDs auf Systemd-Systemen[2] reserviert. Das Reservierungs-API unterstutzt auch Identitatsabbildungen: Anstatt einen fluchtigen 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. Identitatsabbildungen konnen mit delegierten Bereichen kombiniert werden, um einen privilegierten Namensraum zu betreten, aus dem der Container eingerichtet werden kann, der dann anschliessend in einem der delegierten Bereiche ausgefuhrt werden kann. Identitatsabgebildete Benutzer unterligen den BPF-LSM-Schreibbeschrankungen nicht, anders als fluchtige Bereiche. Zusatzlich unterstutzt 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 Veranderung von Dateien, die dem fremden UID-Bereich gehoren. Der Dienst stellt API-Aufrufe bereit, um Einhangungen (die mittels ihrer Einhangedateideskriptoren gemass des fsmount()-API von Linux referenziert sind), die als erlaubt aufgelistet sind, die Eigentumerschaft eines Cgroup-Unterbaums an den Benutzernamensraum weiterzugeben und ein virtuelles Ethernet-Geratepaar an den Benutzernamensraum zu delegieren. Wird dies zusammen benutzt, reicht dies aus, um vollstandig unprivilegierte Container-Umgebungen, wie dies von systemd-nspawn(1) implementiert wird, vollstandig unprivilegierte RootImage= (siehe systemd.exec(5)) oder vollstandig unprivilegierte Plattenabbildwerkzeuge wie systemd-dissect(1) zu implementieren. Dieser Dienst stellt einen Varlink[3]-Dienst bereit: io.systemd.NamespaceResource erlaubt die Registrierung von Benutzernamensraumen und weist ihnen Einhangungen, 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 uber Varlink https://systemd.io/USER_GROUP_API 2. Benutzer, Gruppen, UIDs und GIDs auf Systemd-Systemen https://systemd.io/UIDS-GIDS 3. Varlink https://varlink.org/ UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 260.2 SYSTEMD-NSRESOURCED.SERVICE(8)