libnss_systemd.so.2

BEZEICHNUNG

nss-systemd, libnss_systemd.so.2 - UNIX-Benutzer- und -Gruppennamensauflösung zum Nachschlagen von Benutzern/Gruppen mittels Varlink

ÜBERSICHT

libnss_systemd.so.2

BESCHREIBUNG

nss-systemd ist ein Erweiterungsmodul für die GNU »Name Service Switch« (NSS)-Funktionalität der GNU-C-Bibliothek ( glibc). Es stellt eine UNIX-Benutzer- und -Gruppennamensauflösung für Dienste bereit, die das Nachschlagen von Benutzern-/Gruppendatensätzen mittels Varlink[1] implementieren (für seine Funktionalität DynamicUser=, siehe systemd.exec(5) für Details), systemd-homed.service(8) oder systemd-machined.service(8). Dieses Modul stellt auch sicher, dass die Benutzer und Gruppen »root« und »nobody« (d.h. die Benutzer/Gruppen mit den UIDs/GIDs 0 und 65534) zu allen Zeiten aufgelöst werden können, selbst wenn sie in /etc/passwd oder /etc/group nicht aufgeführt sind oder diese Dateien fehlen. Dieses Modul verwendet bevorzugt systemd-userdbd.service(8) zur Auflösung von Benutzern und Gruppen, funktioniert aber auch, wenn dieser Dienst nicht läuft. Um das NSS-Modul zu aktivieren, fügen Sie »systemd« zu den mit »passwd:«, »group:«, »shadow:« und »gshadow:« in /etc/nsswitch.conf beginnenden Zeilen hinzu. Es wird empfohlen, »systemd« nach dem »files«- oder »compat«-Eintrag in den /etc/nsswitch.conf-Zeilen abzulegen, um sicherzustellen, dass /etc/passwd-, /etc/group-, /etc/shadow- und /etc/gshadow-basierte Abbildungen Vorrang haben.

STATISCHE ERGÄNZUNGS-JSON-BENUTZER/GRUPPEN-DATENSÄTZE

Neben den Benutzer-/Gruppendatensätzen, die über die vorgenannten Varlink-IPC-Schnittstellen erlangt werden und die synthetisierten Konten von root und nobodoy, stellt dieses Modul auch Benutzer- und Gruppenkonten dem System zur Verfügung, die in statischen Ergänzungsdateien in den Verzeichnissen /etc/userdb/, /run/userdb/, /run/host/userdb/ und /usr/lib/userdb/ definiert sind. Dies ist ein einfacher Mechanismus, statische Benutzer- und Gruppendatensätze mittels JSON-Ergänzungsdateien bereitzustellen. Solche Benutzerdatensätze sollten in dem in der Spezifikation JSON-Benutzerdatensätze[2] beschriebenen Format bereitgestellt werden und in eines der vorgenannten Verzeichnisse unter einem Dateinamen abgelegt werden, der aus dem Benutzernamen mit angehängtem .user besteht; die Datei sollte für alle lesbar sein. Es sollte auch ein Symlink, der nach der UID des Benutzerdatensatzes benannt, dezimal formatiert und mit angehängtem .user versehen ist, erstellt werden, der auf die primäre Datensatzdatei zeigt, um Nachschlagen nach sowohl dem Benutzer als auch der UID zu ermöglichen. Es können optional auch privilegierte Benutzerdaten (z.B. gehashte UNIX-Passwörter) bereitgestellt werden und zwar als Paar von getrennten Begleiterdateien mit der Endung .user-privileged. Die Daten sollten in einer regulären Datei gespeichert werden, die nach dem Benutzernamen benannt ist und die Endung .user-privileged trägt und einem Symlink, der darauf zeigt, der nach der verwandten numerischen UID, dezimal formatiert, benannt ist und die gleiche Endung hat. Diese Begleiterdateien sollten nur für root lesbar sein. Beispiel: Ähnlich können Gruppendatensätze, die dem in JSON-Gruppendatensatz[3] beschriebenen Format folgen, definiert werden. Sie verwenden die Endungen .group und .group-privileged. Die primären Benutzer-/Gruppendatensätze (d.h. solche, mit der Endung .user und .group) sollten keinen »privilegierten« Abschnitt enthalten, wie das in der Spezifikation beschrieben ist. Ausschließlich die privilegierten Benutzer-/Gruppendatensatzdateien (d.h. die mit den Endungen .user-privileged und .group-privileged) sollten diesen Abschnitt enthalten. Beachten Sie, dass die statischen Benutzer-/Gruppendatensätze im Allgemeinen dazu in Konflikt stehende Datensätze /etc/passwd oder/etc/group oder anderen Kontodatenbanken nicht außer Kraft setzen. Bevor diese Dateien entfernt werden, sollte vernünftige Sorgfalt walten gelassen werden, Konflikte bei Benutzer-/Gruppennamen und UIDs/GIDs zu vermeiden.

KONFIGURATION IN /ETC/NSSWITCH.CONF

Hier ist ein Beispiel für eine /etc/nsswitch.conf-Datei, die nss-systemd korrekt aktiviert:

BEISPIEL: DURCH SYSTEMD-MACHINED.SERVICE BEREITGESTELLTE ABBILDUNGEN

Der Container »rawhide« wird mittels systemd-nspawn(1) erzeugt:

SIEHE AUCH

systemd(1), systemd.exec(5), nss-resolve(8), nss-myhostname(8), nss-mymachines(8), systemd-userdbd.service(8), systemd-homed.service(8), systemd-machined.service(8), nsswitch.conf(5), getent(1)

ANMERKUNGEN

1.

Benutzer-/Gruppen-Datensatznachschlage-API über Varlink

2.

JSON-Benutzerdatensätze

3.

JSON-Gruppendatensatz

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <[email protected]> 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