Richtlinien für Benutzer und Gruppen

Es gibt viele Möglichkeiten, die UIDs und GIDs vorab zuzuweisen. Websites, die nur die UIDs und GIDs einiger weniger, nicht unbedingt notwendiger Dienste anpassen möchten, können ein Skript schreiben, um die Einträge mit useradd und groupadd zu erstellen und anschließend unser Paket zu installieren.

Websites, die für eine unbeaufsichtigte Kickstart-Installation benötigte Benutzerkonten vorab zuweisen möchten, stehen vor einem komplexeren Problem. Eine Möglichkeit besteht darin, eine angepasste Version des setup-Pakets mit den gewünschten Benutzern und Gruppen sowie den entsprechenden UID/GID-Zuordnungen in den Dateien /etc/passwd, /etc/shadow und /etc/group zu erstellen. Anschließend wird sichergestellt, dass die Installation dieses Paket anstelle des Standardpakets der Distribution verwendet (indem das Setup-Paket höher versioniert wird, beispielsweise mit einer Epochennummer, und in einer lokalen Paketquelle abgelegt wird, die bei der Installation eingebunden wird, oder indem das Setup-Paket in einem lokalen Spiegel der zu installierenden Pakete durch das eigene ersetzt wird). Da sich das Setup-Paket an oberster Stelle der Abhängigkeitsstruktur befindet, wird es vor allen Paketen installiert, die die darin definierten UIDs und GIDs benötigen.

Die Verwendung bestehender Benutzer und Gruppen, sofern deren symbolische Namen (Benutzer- und Gruppennamen) bereits im System vorhanden sind, ermöglicht es dem Systemadministrator, die UIDs und GIDs nach Belieben anzupassen. Dies hat jedoch einen Nachteil, den Systemadministratoren beachten sollten: Falls bereits ein anderes Konto mit diesen Benutzernamen und Gruppennamen existiert, verwendet das Paket dieses Konto.

Nehmen wir beispielsweise an, Sie installieren das Mailman-Paket, das den Benutzer und die Gruppe mailman anlegen möchte, damit die privaten Mailinglistenarchive diesem Benutzer und dieser Gruppe auf der Festplatte gehören. Einer Ihrer lokalen Benutzer hat bereits den Benutzernamen mailman. Bei der Installation des Mailman-Pakets erkennt dieses, dass bereits ein Benutzer mailman existiert, und verwendet dieses Konto für die Verwaltung seiner privaten Archive. Der lokale Benutzer, dem das Mailman-Konto gehört, kann diese privaten Archive dann lesen.

Derzeit gibt es keine Strategie für die Paketierer, um dem entgegenzuwirken. Es obliegt den Systemadministratoren der Website, Konflikte zwischen den von ihren Benutzern und den verwendeten Paketen verwendeten Benutzer- und Gruppennamen zu überwachen und zu beheben.

Um Systembenutzer und -gruppen in Paketen mithilfe dynamischer Zuweisung zu erstellen, muss das Paket eine sysusers.d/<Paketname>.conf-Datei installieren. Falls diese nicht vom Upstream-Projekt bereitgestellt wird, sollte der Paketbetreuer entweder eine separate Source-Datei bereitstellen oder sie während des Paketbaus erstellen.

Zum Beispiel könnte diese Datei für das Paket munge Folgendes enthalten:

(Die Shell ist nicht angegeben, daher sollte die Vorgabe nologin verwendet werden.)

Beim Bauen eines Pakets mit einer sysusers.d-Datei werden automatisch virtuelle Provides-Definitionen für user(…) und group(…) generiert. Installiert rpm ein Paket mit solchen Provides-Definitionen, werden die Benutzer und Gruppen gemäß diesen Definitionen erstellt.

Verwenden Sie rpm -q --qf='[%{SYSUSERS}\n]' …, um die aus dem virtuellen Provides dekodierten Definitionen von Benutzern und Gruppen anzuzeigen.

Bei Fedora-Versionen vor 42 ist die manuelle Erstellung von Benutzern und Gruppen erforderlich.

Die sysusers -Datei muss eine separate Source-Datei sein.

Fügen Sie in der Spec-Datei eine BuildRequires-Anweisung für systemd-rpm-macros hinzu, installieren Sie die sysusers-Datei, verwenden Sie das Makro %sysusers_create_compat, um sie im Abschnitt %pre zu verwenden, (in diesem Beispiel ist die sysusers-Konfigurationsdatei Source3 der Specfile), und das Makro %sysusers_requires_compat, um die Laufzeitabhängigkeiten für den Abschnitt %pre anzugeben:

Diese Form ist zu Fedora 42 und höher kompatibel, und dieselbe Spec-Datei kann für ältere und neuere Versionen verwendet werden. In F42 und höher werden die Makros %sysusers_requires_compat und %sysusers_create_compat als leer expandiert.

Um eine UID und/oder GID zu zuzuweisen, erstellen Sie bitte hier ein Ticket zur Prüfung durch das Fedora Package Committee (FPC). Falls das FPC feststellt, dass Ihr Paket eine statische Soft-UID oder GID benötigt, wird Ihr Antrag genehmigt und an die Betreuer des Pakets setup zur Implementierung weitergeleitet. Da die Anzahl der UIDs und GIDs begrenzt ist, müssen Sie den Bedarf Ihres Pakets an einer statischen Soft-UID im FPC-Ticket begründen. Erläutern Sie, wie die UIDs und GIDs zwischen den Rechnern geteilt werden. Erklären Sie gegebenenfalls auch, warum das Programm nicht stattdessen symbolische Namen (Benutzername und Gruppenname) verwenden kann. Falls eine bestimmte UID oder GID verwendet werden soll, geben Sie diese bitte an und begründen Sie Ihre Wahl (z.B. die vom Upstream-Projekt oder von anderen Distributionen verwendete). Wir werden versuchen, die Anträge in der Reihenfolge ihres Eingangs zu bearbeiten, sofern die gewünschte UID/GID im UID/GID-Bereich des Fedora-Systems verfügbar ist.

Um Benutzer und Gruppen in Paketen mit einer zugewiesenen UID/GID zu erstellen, befolgen Sie die Schritte im Abschnitt zur dynamischen Zuweisung weiter oben, fügen Sie jedoch die UID oder GID in die Spalte ID ein.

Das Paket, das die Definition des Benutzer- oder Gruppenkontos bereitstellt, hat automatisch virtuelle Provides-Anweisungen generiert. Andere Pakete, die sicherstellen möchten, dass Benutzer oder Gruppen existieren, können Requires-Anweisungen für die Benutzer- oder Gruppennamen verwenden.

Zum Beispiel Requires: user(mock) oder Requires: group(man).

rpm erstellt automatisch weiche Abhängigkeiten (Recommends) für Pakete, die Dateien enthalten, die Benutzern und Gruppen gehören. Zukünftig werden diese Abhängigkeiten in Requires geändert.

Die Liste der statisch zugewiesenen Benutzerkonten wird im Paket setup verwaltet: uidgid.