Provided by: manpages-de_2.16-1_all 
BEZEICHNUNG
systemd.exec - Konfiguration der Ausführungsumgebung
ÜBERSICHT
Dienst.service, Socket.socket, Einhängung.mount, Auslagerung.swap
BESCHREIBUNG
Unit-Konfigurationsdateien für Dienste, Sockets, Einhängepunkte und Auslagerungsgeräte nutzen eine
Teilmenge der Konfigurationsoptionen, die die Ausführungsumgebung von gestarteten Prozessen definieren.
Diese Handbuchseite listet die Konfigurationsoptionen auf, die von diesen vier Unit-Typen gemeinsam
benutzt werden. Siehe systemd.unit(5) für die Konfiguration der von allen Unit-Typen gemeinsam benutzten
Optionen und systemd.service(5), systemd.socket(5), systemd.swap(5) und systemd.mount(5) für weitere
Informationen über die Konfigurationsdateioptionen, die für jeden Unit-Typen spezifisch sind. Die
ausführungsspezifischen Konfigurationsoptionen werden in den Abschnitten [Service], [Socket], [Mount]
oder [Swap] konfiguriert, abhängig vom Unit-Typ.
Zusätzlich werden Optionen, die verfügbare Ressourcen mittels Linux Control Groups (cgroups) steuern, in
systemd.resource-control(5) aufgeführt. Diese Optionen ergänzen die hier aufgeführten Optionen.
IMPLIZITE ABHÄNGIGKEITEN
Einige Ausführungsparameter führen zur Ergänzung von zusätzlichen, automatischen Abhängigkeiten:
• Units mit gesetzten WorkingDirectory=, RootDirectory=, RootImage=, RuntimeDirectory=,
StateDirectory=, CacheDirectory=, LogsDirectory= oder ConfigurationDirectory= erhalten automatisch
Abhängigkeiten vom Typ Requires= und After= von allen für den Zugriff auf die festgelegten Pfade
notwendigen Einhängepunkten. Dies ist äquivalent zur expliziten Auflistung in RequiresMountsFor=.
• Ähnlich erhalten Einhänge-Units mit aktiviertem PrivateTmp= automatisch Abhängigkeiten von allen
Einhängungen, die notwendig sind, auf /tmp und /var/tmp zuzugreifen. Sie werden auch automatische
Abhängigkeiten After= von systemd-tmpfiles-setup.service(8) erhalten.
• Units, deren Standardausgabe oder Fehlerausgabe mit dem journal, syslog oder kmsg (oder ihrer
Kombination mit Konsolenausgabe, siehe unten) verbunden ist, erlangen automatisch Abhängigkeiten vom
Typ After= von systemd-journald.socket.
PFADE
Die folgenden Einstellungen können zur Änderung der Sicht eines Dienstes auf das Dateisystem verwandt
werden. Bitte beachten Sie, dass die Pfade absolut sein müssen und keine »..«-Pfadkomponente enthalten
dürfen.
WorkingDirectory=
Akzeptiert einen Verzeichnispfad, der relativ zu dem durch RootDirectory= festgelegten
Wurzelverzeichnis des Dienstes ist, oder den besonderen Wert »~«. Setzt das Arbeitsverzeichnis für
ausgeführte Prozesse. Falls auf »~« gesetzt, wird das Home-Verzeichnis des in User= festgelegten
Benutzers verwandt. Falls nicht gesetzt, ist dies standardmäßig das Wurzelverzeichnis, falls Systemd
als eine Systeminstanz läuft und das Home-Verzeichnis des respektiven Benutzers, falls es als
Benutzer läuft. Falls der Einstellung das Zeichen »-« vorangestellt wird, wird ein fehlendes
Arbeitsverzeichnis nicht als fatal betrachtet. Falls RootDirectory=/RootImage= nicht gesetzt ist,
dann ist WorkingDirectory= relativ zu der Wurzel des Systems, das den Diensteverwalter betreibt.
Beachten Sie, dass das Setzen dieses Parameters die Hinzunahme von zusätzlichen Abhängigkeiten (siehe
oben) auslösen kann.
RootDirectory=
Akzeptiert einen Verzeichnispfad, der relativ zum Wurzelverzeichnis des Rechners (d.h. der Wurzel des
Systems, auf dem der Diensteverwalter läuft) ist. Setzt mit dem Systemaufruf chroot(2) das
Wurzelverzeichnis für ausgeführte Prozesse. Falls dies verwandt wird, muss sichergestellt werden,
dass das Prozessprogramm und alle seine zugehörigen Dateien in dem chroot()-Gefängnis verfügbar sind.
Beachten Sie, dass das Setzen dieses Parameters die Hinzunahme von zusätzlichen Abhängigkeiten (siehe
oben) auslösen kann.
Die Einstellungen MountAPIVFS= und PrivateUsers= sind inbesondere im Zusammenhang mit RootDirectory=
nützlich. Für Details siehe unten.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
RootImage=
Akzeptiert einen Pfad zu einem Blockgeräteknoten oder einer regulären Datei als Argument. Dieser
Aufruf ist ähnlich RootDirectory=, hängt allerdings eine Dateisystemhierarchie aus einem
Blockgeräteknoten oder einer Loopback-Datei anstatt eines Verzeichnisses ein. Der Geräteknoten oder
die Dateisystemabbilddatei müssen ein Dateisystem ohne Partitionstabelle enthalten oder ein
Dateisystem innerhalb einer MBR/MS-DOS- oder GPT-Partitionstabelle mit nur einer einzelnen
Linux-kompatiblen Partition oder eine Gruppe von Dateisystemen innerhalb einer GPT-Partitionstabelle,
die der Spezifikation für auffindbare Partitionen[1] folgt.
Wenn DevicePolicy= auf »closed« oder »strict« gesetzt ist oder auf »auto« und DeviceAllow= gesetzt
ist, dann fügt diese Einstellung /dev/loop-control mit Modus rw, »block-loop« und »block-blkext« mit
Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) für die Details über DevicePolicy=
oder DeviceAllow=. Siehe auch nachfolgendes PrivateDevices=, da sie die Einstellungen von
DevicePolicy= ändern könnte.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
MountAPIVFS=
Akzeptiert ein logisches Argument. Falls eingeschaltet, wird ein privater Einhängenamensraum für die
Prozesse der Unit erstellt und die API-Dateisysteme /proc, /sys und /dev darin eingehängt, außer sie
sind bereits eingehängt. Beachten Sie, dass diese Option keinen Effekt zeigt, außer sie wird zusammen
mit RootDirectory=/RootImage= verwandt, da diese drei Einhängungen im Allgemeinen im Rechner sowieso
eingehängt sind und außer wenn das Wurzelverzeichnis geändert wird, der private Einhängenamensraum
eine 1:1-Kopie des Rechners sein wird und diese drei Einhängungen enthalten wird. Beachten Sie, dass
das /dev-Dateisystem des Rechners mit »bind« eingehängt wird, falls diese Option ohne PrivateDevices=
verwandt wird. Um den Dienst mit einer privaten, minimalen Version von /dev/ auszuführen, kombinieren
Sie diese Option mit PrivateDevices=.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
BindPaths=, BindReadOnlyPaths=
Konfiguriert Unit-spezifische Bind-Einhängungen. Eine Bind-Einhängung macht eine bestimmte Datei oder
Verzeichnis an einem zusätzlichen Ort in der Betrachtung der Unit verfügbar. Alle mit dieser Option
erstellten Bind-Einhängungen sind für die Unit spezifisch und nicht innerhalb der Einhängetabelle des
Rechners sichtbar. Diese Option erwartet eine Leerraum-getrennte Liste von Bind-Einhängedefinitionen.
Jede Definition besteht aus einem durch Doppelpunkte getrennten Tripel von Quellpfad, Zielpfad und
Optionszeichenkette, wobei die letzteren zwei optional sind. Falls nur ein Quellpfad festgelegt wird,
wird angenommen, dass Quelle und Ziel identisch sind. Die Optionszeichenkette kann entweder »rbind«
oder »norbind« sein, um eine rekursive oder nichtrekursive Bind-Einhängung zu konfigurieren. Falls
der Zielpfad ausgelassen wird, muss auch die Optionszeichenkette ausgelassen werden. Jeder
Bind-Einhängungsdefinition kann »-« vorangestellt werden, wodurch sie ignoriert wird, falls der
Quellpfad nicht existiert.
BindPaths= erstellt reguläre, schreibbare Bind-Einhängungen (außer die Quelldateisystemeinhängung ist
bereits nur-lesbar markiert), während BindReadOnlyPaths= nur-lesbare Bind-Einhängungen erstellt.
Diese Einstellungen können mehr als einmal verwandt werden, jede Verwendung hängt sich an die Liste
der Bind-Einhängungen der Unit an. Falls zu einer dieser zwei Optionen die leere Zeichenkette
zugewiesen wird, wird die gesamte Liste an vorher definierten Bind-Einhängungen dazu zurückgesetzt.
Beachten Sie, dass in diesem Fall sowohl die nur-lesbaren als auch die regulären Bind-Einhängungen
zurückgesetzt werden, unabhängig davon, welche der zwei Einhängungen verwandt wird.
Diese Option ist besonders nützlich, wenn RootDirectory=/RootImage= verwandt wird. In diesem Fall
bezieht sich der Quellpfad auf einen Pfad im Dateisystem des Rechners, während der Zielpfad sich auf
einen Pfad unterhalb des Wurzelverzeichnisses der Unit bezieht.
Beachten Sie, dass das Zielverzeichnis existieren oder Systemd in der Lage sein muss, es zu
erstellen. Daher ist es nicht möglich, diese Option für Einhängepunkte, die unterhalb von in
InaccessiblePaths= oder unter /home/ und anderen geschützten Verzeichnissen verschachtelt sind, zu
verwenden, falls ProtectHome=yes festgelegt ist. Stattdessen sollte TemporaryFileSystem= mit »:ro«
oder ProtectHome=tmpfs verwandt werden.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
ZUGANGSDATEN
Diese Optionen sind nur für Systemdienste verfügbar und werden nicht für Dienste, die in
benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstützt.
User=, Group=
Setzt den UNIX-Benutzer oder die -Gruppe, unter der der Prozess ausgeführt wird. Akzeptiert einen
einzelnen Benutzer- oder Gruppennamen oder eine numerische Kennung als Argument. Für Systemdienste
(Dienste, die vom Systemdiensteverwalter, d.h. PID 1, ausgeführt werden) und für Benutzerdienste des
Benutzers root (Dienste, die von der Instanz von root von systemd --user verwaltet werden) ist die
Vorgabe »root«, aber User= kann zur Festlegung eines anderen Benutzers verwandt werden. Für
Benutzerdienste von allen anderen Benutzern ist das Umschalten auf eine andere Benutzeridentität
nicht erlaubt, daher ist die einzige gültige Einstellung der Benutzer, unter dem der Diensteverwalter
selbst läuft. Falls keine Gruppe gesetzt ist, wird die Vorgabegruppe des Benutzers verwandt. Diese
Einstellung beeinflusst keine Befehle, deren Befehlszeile ein »+« vorangestellt ist.
Beachten Sie, dass Einschränkungen bei der Namenssyntax der Benutzer/Gruppen erzwungen werden: der
festgelegte Name darf nur aus den Zeichen a-z, A-Z, 0-9, »_« und »-« (außer beim ersten Zeichen, das
eines aus a-z, A-Z oder »_« sein muss, d.h. Zahlen und »-« sind nicht als erstes Zeichen erlaubt)
bestehen. Der Benutzer-/Gruppenname muss mindestens ein und maximal 31 Zeichen enthalten. Diese
Einschränkungen werden erzwungen, um Mehrdeutigkeiten zu vermeiden und um sicherzustellen, dass
Benutzer-/Gruppennamen und Unit-Dateien zwischen Linux-Systemen portierbar bleiben.
Wenn dies zusammen mit DynamicUser= verwandt wird, wird der festgelegte Benutzer-/Gruppename
dynamisch zum Startzeitpunkt des Dienstes zugewiesen und beim Beenden des Dienstes wieder freigegeben
— außer er ist bereits statisch zugewiesen (siehe unten). Falls DynamicUser= nicht verwandt wird,
muss der festgelegte Benutzer und die festgelegte Gruppe spätestens beim Startmoment des Dienstes
statisch in der Benutzerdatenbank erzeugt worden sein, beispielsweise mit der Einrichtung
sysusers.d(5), die beim Systemstart oder zum Zeitpunkt der Paketinstallation angewandt wird.
Falls die Einstellung User= verwandt wird, wird die Liste der zusätzlichen Gruppen aus der
festgelegten Standardgruppenliste des Benutzers, wie dies durch die Benutzer- und Gruppendatenbank
des Systems definiert ist, initialisiert. Zusätzliche Gruppen können durch die Einstellung
SupplementaryGroups= konfiguriert werden (siehe unten).
DynamicUser=
Akzeptiert einen logischen Parameter. Falls gesetzt, wird ein UNIX-Benutzer-/Gruppenpaar dynamisch
beim Start der Unit erstellt und wieder freigegeben, sobald die Unit beendet wird. Der Benutzer und
die Gruppe wird nicht zu /etc/passwd oder /etc/group hinzugefügt, sondern zur Laufzeit vorübergehend
verwaltet. Das Glibc-NSS-Modul nss-systemd(8) stellt eine Integration dieser dynamischen
Benutzer/Gruppen in die Benutzer- und Gruppendatenbanken des Systems bereit. Die Benutzer- und
Gruppennamen können mit User= und Group= (siehe oben) konfiguriert werden. Falls diese Optionen nicht
verwandt werden und dynamische Benutzer-/Gruppenzuweisung für eine Unit aktiviert ist, wird der Name
des dynamischen Benutzers/der dynamischen Gruppe implizit vom Unit-Namen abgeleitet. Falls der
Unit-Name ohne die Typ-Endung als gültiger Benutzername geeignet ist, wird er direkt verwandt,
andernfalls wird ein Name, der einen Hash davon integriert, verwandt. Falls ein statisch zugewiesener
Benutzer oder eine statisch zugewiesene Gruppe des konfigurierten Namens bereits existiert, wird
diese verwandt und kein dynamischer Benutzer/keine dynamische Gruppe wird zugewiesen. Beachten Sie,
dass es notwendig ist, dass der statische Benutzer mit dem Namen bereits existiert, falls User=
festgelegt wurde und die statische Gruppe mit dem Namen bereits existiert. Entsprechend ist es
notwendig, dass die statische Gruppe mit dem Namen bereits existiert, falls Group= festgelegt wurde
und der statische Benutzer mit dem Namen bereits existiert. Dynamische Benutzer/Gruppen werden aus
dem UID/GID-Bereich 61184…65519 zugewiesen. Es wird empfohlen, diesen Bereich für reguläre System-
oder Anmeldebenutzer zu vermeiden. Zu jedem Zeitpunkt ist eine UID/GID aus diesem Bereich nur keinem
oder einem/einer verwandten Benutzer/Gruppe dynamisch zugewiesen. Nachdem eine Unit beendet wurde,
werden allerdings UIDs/GIDs wiederbenutzt. Es sollte Vorsicht walten gelassen werden, dass jeder
Prozess, der als Teil einer Unit läuft, für die dynamische Benutzer/Gruppen aktiviert sind, keine
Dateien oder Verzeichnisse, die diesen Benutzern/Gruppen gehören, zurücklässt, da eine andere Unit
später die gleiche UID/GID zugewiesen bekommen kann, und daher Zugriff auf diese Dateien oder
Verzeichnisse erlangen kann. Die Aktivierung von DynamicUser= impliziert RemoveIPC= und PrivateTmp=
(was nicht deaktiviert werden kann). Dies stellt sicher, dass die Lebensdauer von IPC-Objekten und
temporären Dateien, die von dem ausgeführten Prozess erstellt wurden, an die Laufzeit des Dienstes
gebunden ist, und damit die Lebensdauer des dynamischen Benutzers/der dynamischen Gruppe. Da /tmp/
und /var/tmp/ normalerweise die einzigen global schreibbar Verzeichnisse auf einem System sind,
stellt dies sicher, dass eine Unit, die dynamische Benutzer-/Gruppenzuweisungen einsetzt, keine
Dateien nach der Beendigung hinterlassen kann. Desweiteren werden NoNewPrivileges= und
RestrictSUIDSGID= implizit aktiviert (und können nicht deaktiviert werden), um sicherzustellen, dass
aufgerufene Prozesse nicht aus SUID/SGID-Dateien oder Verzeichnissen Nutzen ziehen oder diese
erstellen können. Darüberhinaus sind ProtectSystem=strict und ProtectHome=read-only impliziert, die
damit verhindern, dass der Dienst an beliebige Dateisystemstellen schreibt. Um dem Dienst das
Schreiben in bestimmte Verzeichnisse zu erlauben, müssen diese mittels ReadWritePaths= explizit
erlaubt werden; dabei ist drauf zu achten, dass die Wiederbenutzung von UIDs/GIDs keine
Sicherheitsprobleme mit vom Dienst erstellten Dateien hervorruft. Verwenden Sie RuntimeDirectory=
(siehe unten), um dem Dienst ein schreibbares Laufzeitverzeichnis zuzuweisen, das von dem dynamischen
Benutzer/der dynamischen Gruppe besessen und automatisch beim Beenden der Unit entfernt wird.
Verwenden Sie StateDirectory=, CacheDirectory= und LogsDirectory=, um eine Gruppe an schreibbaren
Verzeichnissen für einen bestimmten Zweck dem Dienst zuzuweisen und dabei sicherzustellen, dass sie
vor Schwachstellen aufgrund der UID-Wiederbenutzung geschützt sind (siehe unten). Falls diese Option
aktiviert ist, sollte aufgepasst werden, dass die Prozesse der Unit keinen Zugriff auf Verzeichnisse
außerhalb dieser explizit konfigurierten und verwalteten bekommen. Verwenden Sie inbesondere nicht
BindPaths= und seien Sie vorsichtig mit der Übergabe von AF_UNIX-Dateideskriptoren für
Verzeichnisdateideskriptoren, da dieses Prozessen erlauben würde, Dateien oder Verzeichnisse zu
erstellen, die dem dynamischen Benutzer/der dynamischen Gruppe gehören und nicht dem Lebenszyklus und
den Zugriffsgarantien des Dienstes unterliegen. Standardmäßig »off«.
SupplementaryGroups=
Setzt die zusätzlichen Gruppen, unter denen die Prozesse ausgeführt werden. Dies akzeptiert eine
Leerzeichen-getrennte Liste von Gruppennamen oder -Kennungen. Diese Option kann mehr als einmal
angegeben werden, dann werden alle aufgeführten Gruppen als zusätzliche Gruppen gesetzt. Wird die
leere Zeichenkette zugewiesen, dann wird die Liste der zusätzlichen Gruppen zurückgesetzt und alle
Zuweisungen davor werden unwirksam. Auf jeden Fall setzt diese Option nicht die Liste der in der
Systemgruppendatenbank für den Benutzer konfigurierten zusätzlichen Gruppen außer Kraft sondern
erweitert sie. Dies betrifft nicht Befehle, denen »+« vorangestellt ist.
PAMName=
Setzt den PAM-Dienstenamen, um darunter eine Sitzung einzurichten. Falls gesetzt, wird der
ausgeführte Prozess als eine PAM-Sitzung unter dem festgelegten Dienstenamen registriert. Dies ist
nur in Zusammenspiel mit der Einstellung User= nützlich und wird sonst ignoriert. Falls nicht
gesetzt, wird keine PAM-Sitzung für den ausgeführten Prozess eröffnet. Siehe pam(8) für Details.
Beachten Sie, dass für jede Unit, die diese Option einsetzt, ein PAM-Sitzungshandhabungsprozess als
Teil der Unit verwaltet und aktiv gehalten wird, solange die Unit aktiv ist, um sicherzustellen, dass
geeignete Aktionen unternommen werden können, wenn die Unit und damit die PAM-Sitzung beendet wird.
Dieser Prozess heißt »(sd-pam)« und ist ein direkter Kindprozess des Hauptprozesses der Unit.
Beachten Sie, dass es sehr wahrscheinlich ist (abhängig von der PAM-Konfiguration), dass der
Haupt-Unit-Prozess in seine eigene Sitzungsgeltungsbereich-Unit migriert wird, wenn diese Option für
eine Unit verwandt und sie aktiviert wird. Dieser Prozess wird daher zwei Units zugeordnet sein: der
Unit, in der er ursprünglich gestartet wurde (und für die PAMName= konfiguriert wurde) und der
Sitzungsgeltungsbereichs-Unit. Jeder Kindprozess dieses Prozesses wird allerdings nur der
Sitzungsgeltungsbereichs-Unit zugeordnet sein. Dies hat Auswirkungen, wenn das in Kombination mit
NotifyAccess=all verwandt wird, da diese Kindprozesse nicht in der Lage sein werden, Änderungen an
der usprünglichen Unit über Benachrichtigungsmeldungen zu erreichen. Es wird angenommen, dass diese
Nachrichten zu der Sitzungsgeltungsbereichs-Unit und nicht der ursprünglichen Unit gehören. Es wird
daher nicht empfohlen, PAMName= in Kombination mit NotifyAccess=all zu verwenden.
CAPABILITIES
Diese Optionen sind nur für Systemdienste verfügbar und werden nicht für Dienste, die in
benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstützt.
CapabilityBoundingSet=
Steuert, welche Capabilities in der Capability-Begrenzungsmenge für den ausgeführten Prozess
aufgenommen werden. Siehe capabilities(7) für Details. Akzeptiert eine Leerzeichen-getrennte Liste
von Capability-Namen, z.B. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. Aufgeführte Capabilities
werden in die Begrenzungsmenge aufgenommen, alle anderen werden entfernt. Falls der Liste von
Capabilities »~« vorangestellt wird, werden alle bis auf die aufgeführten Capabilities aufgenommen,
die Wirkung der Zuweisung invertiert. Beachten Sie, dass diese Option auch die respektiven
Capabilities in der effektiven, erlaubten und vererbbaren Capability-Menge betrifft. Falls diese
Option nicht verwandt wird, wird die Capability-Begrenzungsmenge bei der Prozessausführung nicht
verändert, daher werden keine Begrenzungen bezüglich der Capabilities des Prozesses erzwungen. Diese
Option kann mehr als einmal auftauchen, die Begrenzungsmengen werden mit ODER zusammengeführt oder
mit UND, falls den Zeilen »~« vorangestellt wird (siehe unten). Falls dieser Option die leere
Zeichenkette zugewiesen wird, wird die Begrenzungsmenge auf die leere Capability-Menge zurückgesetzt
und alle vorhergehenden Einstellungen haben keine Wirkung. Falls auf »~« (ohne weiteres Argument)
gesetzt, wird die Begrenzungsmenge auf die komplette Menge der verfügbaren Capabilities zurückgesetzt
und alle vorhergehenden Einstellungen zurückgenommen. Dies betrifft nicht Befehle, denen »+«
vorangestellt wurde.
Beispiel: Falls eine Unit die Einstellunng
CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=CAP_B CAP_C
hat, dann werden CAP_A, CAP_B und CAP_C gesetzt. Falls der zweiten Zeile »~« vorangestellt wird, d.h.
CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=~CAP_B CAP_C
dann wird nur CAP_A gesetzt.
AmbientCapabilities=
Steuert, welche Capabilities in der Umgebungs-Capability-Menge für den ausgeführten Prozess
aufgenommen werden. Akzeptiert eine Leerzeichen-getrennte Liste von Capability-Namen, z.B.
CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. Diese Option kann mehr als einmal auftauchen, die
Umgebungsmengen werden zusammengeführt (siehe Beispiele oben in CapabilityBoundingSet=). Falls der
Liste von Capabilities »~« vorangestellt wird, werden alle bis auf die aufgeführten Capabilities
aufgenommen, die Wirkung der Zuweisung invertiert. Falls die leere Zeichenkette dieser Option
zugewiesen wird, wird die Umgebungsmenge auf die leere Capability-Menge zurückgesetzt und alle
vorhergehenden Einstellungen haben keine Wirkung. Falls auf »~« (ohne weiteres Argument) gesetzt,
wird die Umgebungsmenge auf die komplette Menge der verfügbaren Capabilities zurückgesetzt und alle
vorhergehenden Einstellungen zurückgenommen. Beachten Sie, dass die Hinzunahme von Capabilities in
die Umgebungsmenge sie auch zu der vererbbaren Menge des Prozesses hinzufügt.
Umgebungs-Capabilitymengen sind nützlich, falls Sie einen Prozess als nicht privilegierter Benutzer
ausführen wollen, ihm aber dennoch einige Capabilities geben möchten. Beachten Sie, dass in diesem
Fall die Option keep-caps automatisch zu SecureBits= hinzugefügt wird, um die Capabilities über den
Benutzerwechsel hinweg zu erhalten. AmbientCapabilities= betrifft keine Befehle, denen »+«
vorangestellt ist.
SICHERHEIT
NoNewPrivileges=
Akzeptiert ein logisches Argument. Falls wahr, wird sichergestellt, dass der Diensteprozess und
sämtliche seiner Kindprozesse niemals mittels execve() neue Privilegien erlangen können (z.B. mittels
Setuid- oder Setgid-Bits oder Dateisystem-Capabilities). Dies ist die einfachste und effektivste Art,
sicherzustellen, dass ein Prozess und seine Kinder niemals wieder Privilegien erhöhen können.
Standardmäßig falsch, aber bestimmte Einstellungen setzen dies außer Kraft und ignorieren den Wert
dieser Einstellung. Dies ist der Fall, wenn SystemCallFilter=, SystemCallArchitectures=,
RestrictAddressFamilies=, RestrictNamespaces=, PrivateDevices=, ProtectKernelTunables=,
ProtectKernelModules=, MemoryDenyWriteExecute=, RestrictRealtime=, RestrictSUIDSGID=, DynamicUser=
oder LockPersonality= festgelegt werden. Beachten Sie, dass selbst diese Einstellung durch sie außer
Kraft gesetzt wird, systemctl show zeigt den ursprünglichen Wert dieser Einstellung. Siehe auch
Schalter »Keine neuen Privilegien«[2].
SecureBits=
Steuert die Menge der sicheren Bits für den ausgeführten Prozess. Akzeptiert eine durch Leerzeichen
getrennte Kombination von Optionen aus der folgenden Liste: keep-caps, keep-caps-locked,
no-setuid-fixup, no-setuid-fixup-locked, noroot und noroot-locked. Diese Option darf mehr als einmal
auftauchen, dann werden die sicheren Bits ODER-verknüpft. Falls der Option die leere Zeichenkette
zugewiesen wird, werden die Bits auf 0 zurückgesetzt. Dies betrift keine Befehle, denen »+«
vorangestellt ist. Siehe capabilities(7) für Details.
MANDATORY ACCESS CONTROL
Diese Optionen sind nur für Systemdienste verfügbar und werden nicht für Dienste, die in
benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstützt.
SELinuxContext=
Setzt den SELinux-Sicherheitskontext des ausgeführten Prozesses. Falls gesetzt, wird dies den
automatischen Domain-Übergang außer Kraft setzen. Allerdings muss die Policy den Übergang erlauben.
Diese Anweisung wird ignoriert, falls SELinux deaktiviert ist. Falls »-« vorangestellt ist, werden
alle Fehler ignoriert. Dies betrifft keine Befehle, denen »+« vorangestellt ist. Siehe setexeccon(3)
für Details.
AppArmorProfile=
Akzeptiert einen Profilnamen als Argument. Der von der Unit ausgeführte Prozess wird beim Start in
dieses Profil umschalten. Profile müssen bereits in den Kernel geladen sein oder die Unit schlägt
fehl. Dies führt zu einer leeren Aktion, falls AppArmor nicht aktiviert ist. Falls ein »-«
vorangestellt ist, werden alle Fehler ignoriert. Dies betrifft keine Befehle, denen »+« vorangestellt
ist.
SmackProcessLabel=
Akzeptiert ein SMACK64-Sicherheits-Label als Argument. Der durch diese Unit ausgeführte Prozess wird
unter diesem Label gestartet und SMACK wird darauf basierend entscheiden, ob die Ausführung des
Prozesses erlaubt ist. Der Prozess wird weiter unter dem hier festgelegten Label laufen, außer falls
das Programm seinen eigenen SMACK64EXEC-Label hat, in welchem Falle der Prozess dazu übergehen wird,
unter diesem Label zu laufen. Falls nicht angegeben, wird der Label verwandt, unter dem Systemd
läuft. Diese Anweisung wird ignoriert, falls SMACK deaktiviert ist.
Diesem Wert kann »-« vorangestellt werden, wodurch alle Fehler ignoriert werden. Ein leerer Wert kann
festgelegt werden, um alle vorhergehenden Zuweisungen zurückzusetzen. Dies betrifft keine Befehle,
denen »+« vorangestellt ist.
PROZESSEIGENSCHAFTEN
LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, LimitAS=,
LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=,
LimitRTTIME=
Setzt die weichen und harten Beschränkungen für verschiedene Ressourcen für ausgeführte Prozesse.
Siehe setrlimit(2) für Details über das Ressourcenbegrenzungskonzept. Ressourcenbegrenzungen können
in zwei Formaten festgelegt werden: entweder als einzelner Wert, um eine bestimmte weiche und harte
Begrenzung auf den gleichen Wert zu setzen, oder als Doppelpunkt-getrenntes Paar weich:hart, um beide
Begrenzungen individuell zu setzen (z.B. »LimitAS=4G:16G«). Verwenden Sie die Zeichenkette infinity,
um keine Begrenzung für eine bestimmte Ressource zu konfigurieren. Die multiplikativen Endungen K, M,
G, T, P und E (auf Basis 1024) können für Ressourcenbegrenzungen, die in Bytes gemessen werden,
verwandt werden (z.B. LimitAS=16G). Für Begrenzungen, die sich auf Zeitwerte beziehen, können die im
Englischen normalen Zeiteinheiten ms, s, min, h und so weiter verwandt werden (siehe systemd.time(7)
für Details). Beachten Sie, dass die Standardzeiteinheit als Sekunden impliziert ist, falls keine
Zeiteinheit für LimitCPU= angegeben ist. Für LimitRTTIME= wird als Standardeinheit Mikrosekunden
impliziert. Beachten Sie, dass die effektive Granularität der Begrenzungen ihre Durchsetzung
beeinflussen könnte. Beispielsweise werden für LimitCPU= festgelegte Zeitbeschränkungen implizit auf
Vielfache von 1s aufgerundet. Für LimitNICE= kann der Wert in zwei Syntaxen festgelegt werden: falls
ihm »+« oder »-« vorangestellt wird, wird der Wert als regulärer Linux-Nice-Wert im Bereich -20..19
interpretiert. Falls ihm so etwas nicht vorangestellt wird, wird der Wert als roher
Ressourcenbegrenzungsparameter im Bereich 0..40 (wobei 0 äquivalent zu 1 ist) verstanden.
Beachten Sie, dass die meisten der mit diesen Optionen konfigurierten Ressourcenbeschränkungen
prozessbezogen sind. Prozesse können einen Fork durchführen, um einen neuen Satz an Ressourcen zu
erlangen. Diese neuen Ressourcen können unabhängig vom ursprünglichen Prozess verbucht werden und
daher gesetzten Beschränkungen entkommen.Beachten Sie auch, dass LimitRSS= unter Linux nicht
implementiert ist und das Setzen keinen Effekt hat. Oft ist es ratsam, die in
systemd.resource-control(5) aufgeführten Ressourcensteuerungen gegenüber den prozessabhängigen zu
bevorzugen, da sie, auf Dienste als ganzes angewandt, zur Laufzeit verändert werden und im
Allgemeinen ausdrucksstärker sind. Beispielsweise ist MemoryLimit= ein leistungsfähigerer (und
funktionierender) Ersatz für LimitRSS=.
Für System-Units können diese Ressourcenbeschränkungen frei ausgewählt werden. Für Benutzer-Units
(d.h. Units, die als benutzerbezogene Instanz von systemd(1) ausgeführt werden) wird allerdings eine
Begrenzung durch (möglicherweise weiter eingeschränkte) benutzerbezogene Einschränkungen durch das
Betriebssystem erzwungen.
Nicht explizit konfigurierte Ressourcenbeschränkungen für eine Unit verwenden als Vorgabe die in den
verschiedenen in systemd-system.conf(5) verfügbaren Optionen DefaultLimitCPU=, DefaultLimitFSIZE=, …
konfigurierten Werte und – falls sie dort nicht konfiguriert sind – die Kernel- oder
benutzerbezogenen Vorgaben, wie sie durch das Betriebssystem (Letzteres nur für Benutzerdienste,
siehe oben) definiert sind.
Tabelle 1. Ressourcenbegrenzungsanweisungen, ihre äquivalenten Ulimit-Shell-Befehle und die verwandte
Einheit
┌──────────────────┬───────────────────┬─────────────────────────────┐
│ Anweisung │ ulimit-Äquivalent │ Einheit │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitCPU= │ ulimit -t │ Sekunden │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitFSIZE= │ ulimit -f │ Bytes │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitDATA= │ ulimit -d │ Bytes │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitSTACK= │ ulimit -s │ Bytes │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitCORE= │ ulimit -c │ Bytes │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitRSS= │ ulimit -m │ Bytes │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitNOFILE= │ ulimit -n │ Anzahl an Dateideskriptoren │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitAS= │ ulimit -v │ Bytes │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitNPROC= │ ulimit -u │ Anzahl an Prozessen │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitMEMLOCK= │ ulimit -l │ Bytes │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitLOCKS= │ ulimit -x │ Anzahl an Sperren │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitSIGPENDING= │ ulimit -i │ Anzahl von Signalen in der │
│ │ │ Warteschlange │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitMSGQUEUE= │ ulimit -q │ Bytes │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitNICE= │ ulimit -e │ Nice-Stufe │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitRTPRIO= │ ulimit -r │ Echtzeitpriorität │
├──────────────────┼───────────────────┼─────────────────────────────┤
│ LimitRTTIME= │ Kein Äquivalent │ Mikrosekunden │
└──────────────────┴───────────────────┴─────────────────────────────┘
UMask=
Steuert die Dateimoduserstellungsmaske. Akzeptiert einen Zugriffsmodus in oktaler Notation. Siehe
umask(2) für Details. Standardmäßig 0022.
KeyringMode=
Steuert, wie der Kernelsitzungsschlüsselbund für den Dienst eingerichtet wird (siehe
session-keyring(7) für Details über den Sitzungsschlüsselbund). Akzeptiert einen aus inherit,
private, shared. Falls auf inherit gesetzt, wird keine besondere Schlüsselbundeinrichtung vorgenommen
und das Standardverhalten des Kernels wird angewandt. Falls private verwandt wird, wird ein neuer
Sitzungsschlüsselbund bereitgestellt, wenn ein Diensteprozess aufgerufen wird und dieser nicht mit
einem Benutzerschlüsselbund verbunden ist. Dies ist die für Systemdienste empfohlene Einstellung, da
sie sicherstellt, dass mehrere Dienste, die unter der gleichen Systembenutzerkennung laufen
(insbesondere des Benutzers root) ihr Schlüsselmaterial nicht gemeinsam benutzen. Falls shared
verwandt wird, wird ein neuer Schlüsselbund wie für private reserviert, aber der
Benutzerschlüsselbund des mit User= konfigurierten Benutzers wird mit eingebunden, so dass die dem
Benutzer zugeordneten Schlüssel von den Prozessen der Unit angefragt werden können. In diesem Modus
können mehrere Units, die Prozesse unter der selben Benutzerkennung ausführen, Schlüsselmaterial
gemeinsam benutzen. Außer bei der Auswahl von inherit wird die eindeutige Aufrufkennung für die Unit
(siehe unten) als geschützter Schlüssel unter dem Namen »invocation_id« zu dem neu erstellten
Sitzungsschlüsselbund hinzugefügt. Standardmäßig private für Dienste des Systemdiensteverwalters und
inherit für nicht Dienste-Units und für Dienste des Benutzerdiensteverwalters.
OOMScoreAdjust=
Sets the adjustment value for the Linux kernel's Out-Of-Memory (OOM) killer score for executed
processes. Takes an integer between -1000 (to disable OOM killing of processes of this unit) and 1000
(to make killing of processes of this unit under memory pressure very likely). See proc.txt[3] for
details. If not specified defaults to the OOM score adjustment level of the service manager itself,
which is normally at 0.
Use the OOMPolicy= setting of service units to configure how the service manager shall react to the
kernel OOM killer terminating a process of the service. See systemd.service(5) for details.
TimerSlackNSec=
Setzt den Zeitgeberspielraum in Nanosekunden für den ausgeführten Prozess). Der Zeitgeberspielraum
steuert die Genauigkeit der durch Systemd-Zeitgeber ausgelösten Aufwachaktionen. Siehe prctl(2) für
weitere Informationen. Beachten Sie, dass im Gegensatz zu den meisten anderen Zeitdauerdefinitionen
dieser Parameter einen Ganzzahlwert in Nanosekunden akzeptiert, falls keine Einheit angegeben ist. Es
werden auch die normalen Zeiteinheiten verstanden.
Personality=
Steuert, welche Kernelarchitektur uname(2) melden soll, wenn es von Unit-Prozessen aufgerufen wird.
Akzeptiert eine der Architekturkennungen x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, s390 oder s390x.
Welche Personalitätsarchitekturen unterstützt werden, hängt von der Systemarchitektur ab.
Normalerweise unterstützen die 64-Bit-Versionen der verschiedenen Systemarchitekturen die direkte
Entsprechung der 32-Bit-Personalitätsarchitektur, aber keine anderen. Beispielsweise unterstützen
x86-64-Systeme die x86-64- und x86-Personalitäten, aber keine anderen. Die
Personalitätsfunktionalität ist nützlich, wenn 32-Bit-Dienste auf einem 64-Bit-System ausgeführt
werden. Falls nicht angegeben, wird die Personalität nicht verändert und spiegelt daher die
Personalität des Systemkernels wider.
IgnoreSIGPIPE=
Akzeptiert ein logisches Argument. Falls wahr, wird SIGPIPE in dem ausgeführten Prozess ignoriert.
Standardmäßig wahr, da SIGPIPE im Allgemeinen nur in Shell-Pipes nützlich ist.
SCHEDULING
Nice=
Setzt den Vorgabe-Nice-Wert (Scheduling-Priorität) für ausgeführte Prozesse. Akzeptiert eine Ganzzahl
zwischen -20 (höchste Priorität) und 19 (niedrigste Priorität). Siehe setpriority(2) für Details.
CPUSchedulingPolicy=
Setzt die CPU-Scheduling-Richtlinie für ausgeführte Prozesse. Akzeptiert eines aus other, batch,
idle, fifo, rr. Siehe sched_setscheduler(2) für Details.
CPUSchedulingPriority=
Setzt die CPU-Scheduling-Priorität für ausgeführte Prozesse. Der verfügbare Prioritätenbereich hängt
von der ausgewählten CPU-Scheduling-Richtlinie (siehe oben) ab. Für Echtzeit-Scheduling-Richtlinien
kann eine Ganzzahl zwischen 1 (niedrigste Priorität) und 99 (höchste Priorität) verwandt werden.
Siehe sched_setscheduler(2) für Details.
CPUSchedulingResetOnFork=
Akzeptiert ein logisches Argument. Falls wahr, werden erhöhte CPU-Scheduling-Prioritäten und
-Richtlinien zurückgesetzt, wenn ausgeführte Prozesse Fork ausführen und können daher nicht an
Kindprozesse durchsickern. Siehe sched_setscheduler(2) für Details. Standardmäßig falsch.
CPUAffinity=
Steuert die CPU-Affinität des ausgeführten Prozesses. Akzeptiert eine durch Leerraum oder Kommata
getrennte Liste von CPU-Indizes oder -Bereichen. CPU-Bereiche werden durch den unteren und oberen
CPU-Index, getrennt durch einen Bindestrich, festgelegt. Diese Option kann mehr als einmal angegeben
werden; in diesem Fall werden die festgelegten CPU-Affinitätsmasken zusammengeführt. Falls die leere
Zeichenkette zugewiesen wird, wird die Maske zurückgesetzt und alle vorherigen Zuweisungen haben
keinen Effekt. Siehe sched_setaffinity(2) für Details.
NUMAPolicy=
Steuert die NUMA-Speicherrichtlinie des ausgeführten Prozesses. Akzeptiert einen Richtlinientyp,
einer aus: default, preferred, bind, interleave und local. Eine Liste von NUMA-Knoten, die der
Richtlinie zugeordnet werden sollen, muss in NUMAMask= festgelegt werden. Für weitere Details über
jede Richtlinie lesen Sie bitte set_mempolicy(2). Für einen allgemeinen Überblick über die
NUMA-Unterstützung in Linux, siehe numa(7).
NUMAMask=
Steuert die NUMA-Knotenliste, die zusammen mit der ausgewählten NUMA-Richtlinie angewandt wird.
Akzeptiert eine Liste von NUMA-Knoten und hat die gleiche Syntax wie eine Liste von CPUs für die
Option CPUAffinity=. Beachten Sie, dass für die Richtlinien default und local keine Liste von
NUMA-Knoten benötigt und für die Richtlinie preferred ein einzelner NUMA-Knoten erwartet wird.
IOSchedulingClass=
Setzt die E/A-Scheduling-Klasse für ausgeführte Prozesse. Akzeptiert eine Ganzzahl zwischen 0 und 3
oder eine der Zeichenketten none, realtime, best-effort oder idle. Falls dieser Option die leere
Zeichenkette zugewiesen wird, haben alle vorhergehenden Zuweisungen zu IOSchedulingClass= und
IOSchedulingPriority= keinen Effekt. Siehe ioprio_set(2) für Details.
IOSchedulingPriority=
Setzt die E/A-Scheduling-Priorität für ausgeführte Prozesse. Akzeptiert eine Ganzzahl zwischen 0
(höchste Priorität) und 7 (niedrigste Priorität). Die verfügbaren Prioritäten hängen von der
ausgewählten E/A-Scheduling-Klasse (siehe oben) ab. Falls dieser Option die leere Zeichenkette
zugewiesen wird, haben alle vorhergehenden Zuweisungen zu IOSchedulingClass= und
IOSchedulingPriority= keinen Effekt. Siehe ioprio_set(2) für Details.
SANDBOXING
Die nachfolgenden Sandboxing-Optionen bieten eine wirksame Art, die Kontakte des Systems im Hinblick auf
die Prozesse der Unit zu begrenzen. Es wird empfohlen, so viele dieser Optionen wie möglich, ohne die
Betriebsfähigkeit der Prozesse der Unit negativ zu betreffen, einzuschalten. Beachten Sie, dass viele
dieser Sandboxing-Funktionalitäten beschwerdefrei auf Systemen, auf denen der unterliegende
Sicherheitsmechanismus nicht verfügbar ist, ausgeschaltet werden. Beispielsweise hat ProtectSystem= keine
Wirkung, falls der Kernel ohne Namensräume für Dateisysteme gebaut wurde oder falls der Diensteverwalter
in einem Container-Verwalter ausgeführt wird, der dafür sorgt, dass Dateisystem-Namensräume für seine
Nutzlast nicht verfügbar sind. Ähnlich hat RestrictRealtime= auf Systemen keine Wirkung, denen die
Unterstützung für SECCOMP-Systemaufruffilterung fehlt oder in Containern, in denen die Unterstützung
dafür abgeschaltet ist.
Beachten Sie auch, dass einige Sandboxing-Funktionalität im Allgemeinen in Benutzerdiensten (d.h.
Diensten, die vom benutzerbezogenen Diensteverwalter ausgeführt werden) nicht verfügbar ist. Insbesondere
die verschiedenen Einstellungen, die die Unterstützung für Dateisystem-Namensräume benötigen (wie
ProtectSystem=) sind nicht verfügbar, da die zugrundeliegende Kernelfunktionalität nur für privilegierte
Prozesse erreichbar ist.
ProtectSystem=
Akzeptiert ein logisches Argument oder die besonderen Werte »full« oder »strict«. Falls wahr, werden
die Verzeichnisse /usr und /boot für von dieser Unit aufgerufene Prozesse nur lesbar eingehängt.
Falls auf »full« gesetzt, wird auch das Verzeichnis /etc nur lesbar eingehängt. Falls auf »strict«
gesetzt, wird die gesamte Dateisystemhierarchie nur lesbar eingehängt, außer der
API-Dateisystemunterbäume /dev, /proc und /sys (schützen Sie diese Verzeichnisse mittels
PrivateDevices=, ProtectKernelTunables=, ProtectControlGroups=). Diese Einstellung stellt sicher,
dass alle Änderungen an dem vom Lieferanten bereitgestellten Betriebssystem (und optional seiner
Konfiguration und lokaler Einhängungen) für den Dienst verboten sind. Es wird empfohlen, diese
Einstellung für alle langlaufenden Dienste zu aktivieren, außer sie sind an Systemaktualisierungen
beteiligt oder müssen das Betriebssystem auf eine andere Art verändern. Falls diese Option verwandt
wird, kann ReadWritePaths= verwandt werden, um bestimmte Verzeichnisse von dem nur lesbaren Verhalten
auszunehmen. Diese Einstellung ist impliziert, falls DynamicUser= gesetzt ist. Diese Einstellung kann
nicht für alle Fälle den Schutz sicherstellen. Im Allgemeinen hat es die gleichen Begrenzungen wie
ReadOnlyPaths=, siehe unten. Standardmäßig aus.
ProtectHome=
Akzeptiert ein logisches Argument oder die besonderen Werte »read-only« oder »tmpfs«. Falls wahr,
wird der Zugriff auf die Verzeichnisse /home, /root und /run/user entzogen, sie erscheinen für von
der Unit aufgerufene Prozesse leer. Falls auf »read-only« gesetzt, werden die drei Verzeichnisse
stattdessen nur lesbar gesetzt. Falls auf »tmpfs« gesetzt, werden temporäre Dateisysteme auf diesen
drei Verzeichnissen im nur-lesbaren Modus eingehängt. Der Wert »tmpfs« ist nützlich, um
Home-Verzeichnisse, die für die von der Unit aufgerufenen Prozesse nicht relevant sind, zu
verstecken, während gleichzeitig notwendige Verzeichnisse weiterhin sichtbar gemacht werden können,
indem sie mit BindPaths= oder BindReadOnlyPaths= aufgelistet werden.
Setzen dieser Einstellung auf »yes« ist fast äquivalent zum Setzen der drei Verzeichnisse in
InaccessiblePaths=. Ähnlich ist »read-only« fast äquivalent zu ReadOnlyPaths= und »tmpfs« ist fast
äquivalent zu TemporaryFileSystem= mit »:ro«.
Es wird empfohlen, diese Einstellung für alle langlaufenden Dienste (insbesondere solchen zu Netzen)
zu aktivieren, um sicherzustellen, dass sie keinen Zugriff auf private Benutzerdaten bekommen, außer
der Dienst benötigt tatsächlich Zugriff auf die privaten Daten der Benutzer. Diese Einstellung ist
impliziert, falls DynamicUser= gesetzt ist. Diese Einstellung kann nicht für alle Fälle den Schutz
sicherstellen. Im Allgemeinen hat es die gleichen Begrenzungen wie ReadOnlyPaths=, siehe unten.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory=
Diese Optionen akzeptieren eine Leerraum-getrennte Liste von Verzeichnisnamen. Die festgelegten
Verzeichnisnamen müssen relativ sein und dürfen »..« nicht enthalten. Falls gesetzt, werden ein oder
mehrere Verzeichniss(e) mit den festgelegten Namen unterhalb der in der nachfolgenden Tabelle
definierten Orte erstellt (einschließlich ihrer Eltern), wenn die Unit gestartet wird. Auch wird die
entsprechende Umgebungsvariable mit dem vollständigen Pfad der Verzeichnisse definiert. Falls mehrere
Verzeichnisse gesetzt sind, dann werden die Pfade in der Umgebungsvariablen mit dem Doppelpunkt (»:«)
verkettet.
Tabelle 2. Automatische Verzeichniserstellung und Umgebungsvariablen
┌─────────────────────────┬────────────────────────┬────────────────────────┬──────────────────────────┐
│ Verzeichnis │ Unterhalb vom Pfad von │ Unterhalb vom Pfad von │ Umgebungsvariablenmenge │
│ │ System-Units │ Benutzer-Units │ │
├─────────────────────────┼────────────────────────┼────────────────────────┼──────────────────────────┤
│ RuntimeDirectory= │ /run/ │ $XDG_RUNTIME_DIR │ $RUNTIME_DIRECTORY │
├─────────────────────────┼────────────────────────┼────────────────────────┼──────────────────────────┤
│ StateDirectory= │ /var/lib/ │ $XDG_CONFIG_HOME │ $STATE_DIRECTORY │
├─────────────────────────┼────────────────────────┼────────────────────────┼──────────────────────────┤
│ CacheDirectory= │ /var/cache/ │ $XDG_CACHE_HOME │ $CACHE_DIRECTORY │
├─────────────────────────┼────────────────────────┼────────────────────────┼──────────────────────────┤
│ LogsDirectory= │ /var/log/ │ $XDG_CONFIG_HOME/log/ │ $LOGS_DIRECTORY │
├─────────────────────────┼────────────────────────┼────────────────────────┼──────────────────────────┤
│ ConfigurationDirectory= │ /etc/ │ $XDG_CONFIG_HOME │ $CONFIGURATION_DIRECTORY │
└─────────────────────────┴────────────────────────┴────────────────────────┴──────────────────────────┘
Im Falle von RuntimeDirectory= werden die innersten Unterverzeichnisse entfernt, wenn die Unit
gestoppt wird. Es ist möglich, in diesem Fall die festgelegten Verzeichnisse zu erhalten, falls
RuntimeDirectoryPreserve= auf restart oder yes konfiguriert ist (siehe unten). Die mit
StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= festgelegten Verzeichnisse
werden nicht entfernt, wenn die Unit gestoppt wird.
Außer im Fall von ConfigurationDirectory= werden die innersten festgelegten Verzeichnisse dem in
User= und Group= festgelegten Benutzer und der Gruppe gehören. Falls die festgelegten Verzeichnisse
bereits existieren und ihre besitzenden Benutzer und Gruppe nicht auf die konfigurierten passen,
werden alle Dateien und Verzeichnisse unterhalb der festgelegten Verzeichnisse sowie alle
Verzeichnisse selbst rekursiv geändert, so dass die Eigentümerschaft auf die konfigurierte passt.
Falls die festgelegten Verzeichnisse bereits dem richtigen Benutzer und der richtigen Gruppe gehören,
werden als Optimierung alle Dateien und Verzeichnisse darunter unverändert gelassen, selbst falls sie
nicht auf das angeforderte passen. Die Zugriffsmodi der innersten festgelegten Verzeichnisse wird auf
das, was in RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= und
ConfigurationDirectoryMode= festgelegt ist, angepasst.
Diese Optionen implizieren BindPaths= für die festgelegten Pfade. Bei der Kombination mit
RootDirectory= oder RootImage= werden diese Pfade immer innerhalb des Rechners liegen und von dort in
den Dateisystemnamensraum der Unit eingehängt.
Falls DynamicUser= zusammen mit StateDirectory=, CacheDirectory= und LogsDirectory= verwandt wird,
wird es leicht geändert: die Verzeichnisse werden unterhalb /var/lib/private, /var/cache/private bzw.
/var/log/private erstellt, die Verzeichnisse des Rechners sind, die für nicht privilegierte Benutzer
nicht zugreifbar sind. Dadurch wird sichergestellt, dass Zugriff auf diese Verzeichnisse nicht über
die Wiederverwendung dynamischer Benutzerkennungen möglich ist. Symbolische Links werden erstellt, um
diese Unterschiede im Verhalten zu verstecken. Daher tauchen sowohl aus Sicht des Rechners als auch
aus innerhalb der Unit die relevanten Verzeichnisse immer direkt unter /var/lib, /var/cache und
/var/log auf.
Verwenden Sie RuntimeDirectory=, um eine oder mehrere Laufzeitverzeichnisse für die Unit zu verwalten
und ihre Lebensdauer an die Lebensdauer des Daemons zu koppeln. Dies ist insbesonders für nicht
privilegierte Daemons nützlich, die aufgrund fehlender Privilegien keine Laufzeitverzeichnisse in
/run erstellen können und um sicherzustellen, dass die Laufzeitverzeichnisse nach der Verwendung
automatisch bereinigt werden. Für Laufzeitverzeichnisse, die eine komplexere oder andere
Konfiguration oder Lebensdauergarantie benötigen, prüfen Sie den Einsatz von tmpfiles.d(5).
Die durch diese Optionen definierten Verzeichnisse werden immer unter den von Systemd verwandten
Standardpfaden (/var, /run, /etc …) erstellt. Falls der Dienst Verzeichnisse an einem anderen Ort
benötigt, muss ein anderer Mechanismus zu deren Erstellung verwandt werden.
tmpfiles.d(5) stellt Funktionalität bereit, die sich mit diesen Optionen überlappt. Es wird
empfohlen, dass diese Optionen eingesetzt werden, da die Lebensdauer der Verzeichnisse an die
Lebensdauer der Unit gekoppelt ist, und es nicht notwendig ist, sicherzustellen, dass die
tmpfiles.d-Konfiguration vor dem Start der Unit ausgeführt wird.
Um alle von diesen Einstellungen erzeugten Verzeichnisse zu entfernen, verwenden Sie den Befehl
systemctl clean … auf die relevanten Units, siehe systemctl(1) für Details.
Beispiel: Falls eine Systemdienste-Unit
RuntimeDirectory=foo/bar baz
enthält, erstellt der Diensteverwalter /run/foo (falls es noch nicht existiert), /run/foo/bar und
/run/baz. Die Verzeichnisse /run/foo/bar und /run/baz außer /run/foo gehören dem Benutzer und der
Gruppe, die in User= und Group= festgelegt sind und werden entfernt, wenn der Dienst gestoppt wird.
Beispiel: Falls eine Systemdienste-Unit
RuntimeDirectory=foo/bar
StateDirectory=aaa/bbb ccc
enthält, dann wird die Umgebungsvariable »RUNTIME_DIRECTORY« mit »/run/foo/bar« und »STATE_DIRECTORY«
mit »/var/lib/aaa/bbb:/var/lib/ccc« gesetzt.
RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode=,
ConfigurationDirectoryMode=
Legt die Zugriffsmodi der in RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=
bezw. ConfigurationDirectory= festgelegten Verzeichnisse in einer oktalen Zahl fest. Standardmäßig
0755. Siehe »Permissions« in path_resolution(7) für eine Diskussion über die Benennung der
Berechtigungs-Bits.
RuntimeDirectoryPreserve=
Akzeptiert ein logisches Argument oder restart. Falls auf die Vorgabe no gesetzt, werden die in
RuntimeDirectory= festgelegten Verzeichnisse immer entfernt, wenn der Dienst beendet wird. Falls auf
restart gesetzt, werden die Verzeichnisse erhalten, wenn der Dienst sowohl automatisch als auch
manuell neu gestartet wird. Hier bedeutet der automatische Neustart die in Restart= festgelegte
Aktion und manueller Neustart bedeutet die durch systemctl restart foo.service ausgelöste. Falls auf
yes gesetzt, werden die Verzeichnisse nicht entfernt, wenn der Dienst beendet wird. Beachten Sie,
dass die in RuntimeDirectory= festgelegten Verzeichnisse entfernt werden, wenn das System neu
gestartet wird, da das Laufzeitverzeichnis /run ein »tmpfs«-Einhängepunkt ist.
TimeoutCleanSec=
Konfiguriert für die mittels systemctl clean … erbetene Aufräumaktion eine Zeitüberschreitung, siehe
systemctl(1) für Details. Akzeptiert die gewöhnlichen Zeitwerte und ist standardmäßig infinity, d.h.
standardmäßig wird keine Zeitüberschreitung angewandt. Falls eine Zeitüberschreitung konfiguriert
ist, wird die Aufräumaktion zwangsweise beendet, wenn die Zeitüberschreitung erreicht ist,
möglicherweise verbleiben dann Ressourcen auf der Platte.
ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=
Richtet einen neuen Dateisystemnamensraum für ausgeführte Prozesse ein. Diese Optionen können zur
Begrenzung des Zugriffs eines Prozesses auf die Dateisystemhierarchie verwandt werden. Jede
Einstellung akzeptiert eine Leerzeichen-getrennte Liste von Pfaden, die relativ zum Wurzelverzeichnis
des Rechners (d.h. des Systems, das den Diensteverwalter ausführt) ist. Beachten Sie, dass die Pfade
relativ zu dem mit RootDirectory=/RootImage= gesetzten Wurzelverzeichnis aufgelöst werden, falls sie
Symlinks enthalten.
In ReadWritePaths= aufgeführte Pfade sind von innerhalb des Namensraums mit den gleichen Zugriffsmodi
wie von außerhalb zugreifbar. Auf in ReadOnlyPaths= aufgeführte Pfade kann nur lesend zugegriffen
werden, Schreiben wird abgelehnt, selbst falls die normale Dateizugriffssteuerung dies erlauben
würde. Schachteln Sie ReadWritePaths= innerhalb von ReadOnlyPaths=, um schreibbare Unterverzeichnisse
innerhalb nur lesbarer Verzeichnisse bereitzustellen. Verwenden Sie ReadWritePaths=, um bestimmte
Pfade für den Schreibzugriff freizuschalten, falls ProtectSystem=strict verwandt wird.
In InaccessiblePaths= aufgeführte Pfade, einschließlich der Dateisystemhierarchie darunter, werden
für Prozesse innerhalb des Namensraums unzugreifbar gemacht. Dies könnte restriktiver als gewünscht
sein, da es nicht möglich ist, darin ReadWritePaths=, ReadOnlyPaths=, BindPaths= oder
BindReadOnlyPaths= zu verschachteln. Für eine flexiblere Option siehe TemporaryFileSystem=.
Es können auch Pfade, die keine Verzeichnisse sind, angegeben werden. Diese Optionen können mehr als
einmal angegeben werden, dann haben alle aufgeführten Pfade von innerhalb des Namensraums aus
beschränkten Zugriff. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste
zurückgesetzt und alle vorherigen Zuweisungen haben keinen Effekt.
Pfaden in ReadWritePaths=, ReadOnlyPaths= und InaccessiblePaths= kann ein »-« vorangestellt werden,
wodurch sie ignoriert werden, falls sie nicht existieren. Falls ihnen »+« vorangestellt wird, werden
die Pfade als relativ zum Wurzelverzeichnis der Unit akzeptiert, wie dies mit
RootDirectory=/RootImage= konfiguriert ist, statt relativ zum Wurzelverzeichnis des Rechners (siehe
oben). Wenn Sie »-« und »+« auf dem gleichen Pfad kombinieren, verwenden Sie »-« zuerst und danach
»+«.
Beachten Sie, dass diese Einstellungen die Ausbreitung von Einhängungen von den Prozessen einer Unit
zum Rechner abtrennt. Dies bedeutet, dass diese Einstellung nicht für Dienste benutzt werden darf,
die in der Lage sein müssen, Einhängepunkte im Haupteinhängenamensraum zu installieren. Die
ReadWritePaths=- und ReadOnlyPaths=-Ausbreitung in die andere Richtung ist nicht betroffen, d.h.
Einhängungen, die im Rechner erstellt werden, tauchen im Allgemeinen im Namensraum der Unit auf und
Einhängungen, die auf dem Rechner entfernt werden, verschwinden auch dort. Beachten Sie insbesondere,
dass die Einhängeausbreitung vom Rechner zu der Unit dazu führt, dass unveränderte Einhängungen im
Namensraum der Unit erstellt werden, d.h. schreibbare Einhängungen, die auf dem Rechner auftauchen,
werden auch im Namensraum der Unit schreibbar sein, selbst wenn sie zu einem Pfad ausgebreitet
werden, der mit ReadOnlyPaths= markiert ist! Daher wird die Zugriffseinschränkung mit diesen Optionen
nicht auf Untereinhängungen eines Verzeichnisses, das später erstellt wird, ausgeweitet. Dies
bedeutet, dass die durch diese Einstellung angebotene Sperrung nicht vollständig ist und keinen
vollständigen Schutz bietet.
Beachten Sie, dass die Wirkung dieser Einstellung durch privilegierte Prozesse zurückgenommen werden
kann. Um eine wirksame Sandbox-Umgebung für eine Unit einzurichten, wird daher empfohlen, diese
Einstellungen mit entweder CapabilityBoundingSet=~CAP_SYS_ADMIN oder SystemCallFilter=~@mount zu
kombinieren.
Diese Optionen sind nur für Systemdienste verfügbar und werden nicht für Dienste, die in
benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstützt.
TemporaryFileSystem=
Akzeptiert eine Leerzeichen-getrennte Liste von Einhängepunkten für temporäre Dateisysteme (tmpfs).
Falls gesetzt, wird ein neuer Dateisystemnamensraum für ausgeführte Prozesse eingerichtet und in
jeden Einhängepunkt ein temporäres Dateisystem eingehängt. Diese Option kann mehr als einmal
festgelegt werden, dann werden an allen aufgeführten Einhängepunkten temporäre Dateisysteme
eingehängt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste zurückgesetzt
und alle vorherigen Zuweisungen haben keinen Effekt. Jedem Einhängepunkt darf optional ein
Doppelpunkt (»:«) und Einhängeoptionen wie »size=10%« oder »ro« angehängt werden. Standardmäßig wird
jedes temporäre Dateisystem mit »nodev,strictatime,mode=0755« eingehängt. Dies kann durch explizite
Angabe der entsprechenden Einhängeoptionen deaktiviert werden, z.B. »dev« oder »nostrictatime«.
Dies ist nützlich, um Dateien oder Verzeichnisse, die für die von der Unit gestarteten Prozesse nicht
relevant sind, zu verstecken, während auf notwendige Dateien oder Verzeichnisse durch Kombination mit
BindPaths= oder BindReadOnlyPaths= weiterhin zugegriffen werden kann:
Beispiel: Falls eine Unit die Einstellunng
TemporaryFileSystem=/var:ro
BindReadOnlyPaths=/var/lib/systemd
Der durch die Unit aufgerufene Prozess kann dann keine Dateien, Verzeichnisse oder Inhalte unter /var
außer /var/lib/systemd sehen.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
PrivateTmp=
Akzeptiert ein logisches Argument. Falls wahr, wird ein neuer Dateisystemnamensraum für den
ausgeführten Prozess eingerichtet und private /tmp- und /var/tmp-Verzeichnisse darin eingehängt, die
nicht mit Prozessen außerhalb des Namensraums gemeinsam genutzt werden. Dies ist nützlich, um Zugriff
auf temporäre Dateien des Prozesses abzusichern, allerdings ist die gemeinsame Benutzung von Inhalten
über /tmp oder /var/tmp mit anderen Prozessen unmöglich. Falls dies aktiviert ist, werden alle durch
einen Dienst in diesen Verzeichnissen erstellten temporären Dateien entfernt, nachdem der Dienst
gestoppt ist. Standardmäßig falsch. Es ist möglich, zwei oder mehr Units mit dem gleichen privaten
/tmp- und /var/tmp-Namensraum durch Verwendung der Anweisung JoinsNamespaceOf= zu benutzen, siehe
systemd.unit(5) für Details. Diese Einstellung ist impliziert, falls DynamicUser= gesetzt ist. Für
diese Einstellung gelten die gleichen Beschränkungen bezüglich Einhängeausbreitung und Privilegien
wie für ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Aktivieren dieser Einstellung hat den
Seiteneffekt des Hinzufügens der Abhängigkeiten Requires= und After= zu allen für den Zugriff auf
/tmp und /var/tmp notwendigen Einhänge-Units. Desweiteren wird eine implizite After=-Ordnung auf
systemd-tmpfiles-setup.service(8) hinzugefügt.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise,
falls Einhängenamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein
sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
PrivateDevices=
Akzeptiert ein logisches Argument. Falls wahr, wird eine neue /dev-Einhängung für den ausgeführten
Prozess eingerichtet und nur API-Pseudogeräte wie /dev/null, /dev/zero oder /dev/random (sowie das
Pseudo-TTY-Untersystem) hinzugefügt, aber keine physischen Geräte wie /dev/sda, Systemspeicher
/dev/mem, System-Ports /dev/port und andere. Dies ist nützlich, um Zugriff auf physische Geräte für
ausgeführte Prozesse sicher abzustellen. Standardmäßig falsch. Aktivieren dieser Option wird einen
Systemaufruffilter installieren, um systemnahe E/A-Systemaufrufe, die in der Gruppe @raw-io
versammelt sind, zu blockieren, CAP_MKNOD und CAP_SYS_RAWIO aus der Capability-Begrenzungsmenge für
die Unit (siehe oben) zu entfernen und DevicePolicy=closed zu setzen (siehe
systemd.resource-control(5) für Details). Beachten Sie, dass die Verwendung dieser Einstellung die
Ausbreitung von Einhängungen aus dem Dienst zum Rechner trennen wird (Ausbreitung in die umgekehrte
Richtung wird weiterhin funktionieren). Dies bedeutet, dass diese Einstellung nicht für Dienste
benutzt werden kann, die in der Lage sein sollen, Einhängepunkte in dem Haupteinhängeraum zu
installieren. Das neue /dev wird nur lesbar und »noexec« eingehängt. Letzteres könnte alte Programme
beschädigen, die mit mmap(2) aus /dev/zero ausführbaren Speicher einrichten, statt MAP_ANON zu
verwenden. Für diese Einstellung gelten die gleichen Einschränkungen im Hinblick auf
Einhängeausbreitung und Privilegien wie für ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Falls
dies eingeschaltet und im Benutzermodus oder im Systemmodus aber ohne die Capability CAP_SYS_ADMIN
(z.B. durch Setzen von User=) betrieben wird, wird NoNewPrivileges=yes impliziert.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise,
falls Einhängenamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein
sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
PrivateNetwork=
Akzeptiert ein logisches Argument. Falls wahr, wird ein Netzwerknamensraum für die ausgeführten
Prozesse eingerichtet und darin nur das Loopback-Netzwerkgerät »lo« konfiguriert. Dem ausgeführten
Prozess wird kein anderes Netzwerkgerät zur Verfügung stehen. Dies ist nützlich, um den ausgeführten
Prozessen den Netzwerkzugriff zu verweigern. Standardmäßig falsch. Es ist möglich, zwei oder mehr
Units mit dem gleichen privaten Netzwerknamensraum durch Verwendung der Anweisung JoinsNamespaceOf=
zu benutzen, siehe systemd.unit(5) für Details. Beachten Sie, dass diese Option alle
Socket-Einrichtungen, einschließlich AF_NETLINK und AF_UNIX, vom Rechner trennen wird. Effektiv
bedeutet das für AF_NETLINK, dass von systemd-udevd.service(8) empfangene
Gerätekonfigurationsereignisse nicht zu den Prozessen der Unit ausgeliefert werden. Und für AF_UNIX
hat dies den Effekt, dass AF_UNIX-Sockets in dem abstrakten Namensraum des Rechners für Prozesse der
Unit unverfügbar werden (allerdings werden solche im Dateisystem weiterhin zugreifbar sein).
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise,
falls Netzwerknamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein
sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Wenn diese Option auf einer Socket-Unit verwandt wird, dann werden alle im Auftrag dieser Unit
angebundenen Sockets innerhalb eines privaten Netzwerknamensraums angebunden. Dies kann mit
JoinsNamespaceOf= kombiniert werden, um auf Sockets innerhalb von Netzwerknamensräumen von anderen
Diensten auf Anfragen zu warten.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
NetworkNamespacePath=
Akzeptiert einen absoluten Dateisystempfad, der sich auf eine Linux-Netzwerknamensraum-Pseudodatei
bezieht (d.h. einer Datei wie /proc/$PID/ns/net oder einer Bind-Einhängung oder einem Symlink
darauf). Ist dies gesetzt, dann werden aufgerufene Prozesse zu dem durch diesen Pfad referenzierten
Netzwerknamensraum hinzugefügt. Der Pfad muss zum Zeitpunkt des Aufrufs von »fork« auf eine gültige
Netzwerknamensraumdatei zeigen. Falls diese Option verwandt wird, hat PrivateNetwork= keine Wirkung.
Falls diese Option zusammen mit JoinsNamespaceOf= verwandt wird, dann hat sie nur eine Wirkung, falls
diese Unit gestartet wird, bevor alle der aufgeführten Units, die PrivateNetwork= oder
NetworkNamespacePath= konfiguriert haben, gestartet wird, da andernfalls der Netzwerknamensraum
dieser Units neu verwendet wird.
Wenn diese Option auf einer Socket-Unit verwandt wird, dann werden alle Sockets, die im Auftrag
dieser Units angebunden sind, innerhalb des festgelegten Netzwerknamensraums angebunden.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
PrivateUsers=
Akzeptiert ein logisches Argument. Falls wahr, richtet es einen neuen Benutzernamensraum für den
ausgeführten Prozess ein und konfiguriert eine minimale Benutzer- und Gruppenabbildung, die den
Benutzer und die Gruppe »root« sowie den Benutzer und die Gruppe der Unit auf sich selbst und alles
andere auf den Benutzer und die Gruppe »nobody« abbildet. Dies ist nützlich, um die von der Unit
verwandte Benutzer- und Gruppendatenbank sicher vom Rest des Systems abzutrennen und daher eine
effektive Sandbox-Umgebung zu erstellen. Alle Dateien, Verzeichnisse, Prozesse, IPC-Objekte und
andere Ressourcen, die nicht »root« (Benutzer/Gruppe) oder der Unit-eigenen gehören, bleiben von
innerhalb der Unit sichtbar, scheinen aber dem Benutzer und der Gruppe »nobody« zu gehören. Falls
dieser Modus aktiviert ist, werden alle Unit-Prozesse ohne Privilegien in dem
Systembenutzernamensraum ausgeführt (unabhängig davon, ob der Benutzer / die Gruppe der Unit »root«
ist oder nicht). Dies bedeutet insbesondere, dass der Prozess über keine Prozess-Capabilities im
Systembenutzerraum, aber über volle Capabilities innerhalb des Benutzernamensraums des Dienstes
verfügen wird. Einstellungen wie CapabilityBoundingSet= beeinflussen nur Letzteren und es gibt keine
Möglichkeit, zusätzliche Capabilities im Benutzerraum des Systems zu erlangen. Standardmäßig aus.
Diese Einstellung ist insbesondere im Zusammenspiel mit RootDirectory=/RootImage= nützlich, da die
Notwendigkeit, die Benutzer- und Gruppendatenbank im Wurzelverzeichnis und dem Gesamtsystem zu
synchronisieren, reduziert wird, da die einzigen Benutzer und Gruppen, die angepasst werden müssen,
»root«, »nobody« und der Benutzer und die Gruppe der Unit selbst sind.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise,
falls Benutzernamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein
sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
ProtectHostname=
Akzeptiert ein logisches Argument. Wenn gesetzt, wird ein neuer UTS-Namensraum für den ausgeführten
Prozess eingerichtet. Zusätzlich wird die Veränderung des »hostname« oder »domainname« verhindert.
Standardmäßig »off«.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise,
falls UTS-Namensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte,
die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Beachten Sie, dass Änderungen des »hostname« sich nicht länger vom System in den Dienst ausbreiten,
wenn diese Option für einen Dienst aktiviert ist. Daher ist sie nicht für Dienste geeignet, die
dynamisch die Änderung des »hostname« des Systems beachten sollen.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
ProtectKernelTunables=
Akzeptiert ein logisches Argument. Falls wahr, sind die durch /proc/sys, /sys, /proc/sysrq-trigger,
/proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs und /proc/irq verfügbaren
Kernelvariablen für alle Prozesse der Unit nur lesbar. Normalerweise sollten einstellbare
Kernelvariablen nur zum Systemstartzeitpunkt initialisiert werden, beispielsweise über den
Mechanismus sysctl.d(5). Zur Laufzeit müssen wenige Dienste diese schreiben, es wird daher empfohlen,
dies für die meisten Dienste einzuschalten. Für diese Einstellung gelten die gleichen Einschränkungen
bezüglich Einhängeausbreitung und Privilegien wie für ReadOnlyPaths= und verwandte Aufrufe, siehe
oben. Standardmäßig aus. Falls eingeschaltet und im Benutzermodus oder im Systemmodus aber ohne die
Capability CAP_SYS_ADMIN (d.h. für Dienste, bei denen User= gesetzt ist) betrieben, wird
NoNewPrivileges=yes impliziert. Beachten Sie, dass diese Option keine indirekten Änderungen an
Kerneleinstellungen, die durch IPC-Aufrufe an andere Prozesse erfolgen, verhindert. Allerdings kann
InaccessiblePaths= verwandt werden, um die relevanten IPC-Dateisystemobjekte unzugreifbar zu machen.
Falls ProtectKernelTunables= gesetzt ist, wird MountAPIVFS=yes impliziert.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
ProtectKernelModules=
Akzeptiert ein logisches Argument. Falls wahr, wird das explizite Laden von Modulen verweigert. Dies
erlaubt es, das Modulladen und -entladen für modulare Kernel abzuschalten. Es wird empfohlen, dieses
für die meisten Dienste, die keine besonderen Dateisysteme oder zusätzliche Kernelmodule für ihre
Arbeit benötigen, einzuschalten. Standardmäßig aus. Einschalten dieser Option entfernt CAP_SYS_MODULE
aus der Capability-Begrenzungsmenge für die Unit und installiert einen Systemaufruffilter, um
Modulsystemaufrufe zu blockieren; sie macht auch /usr/lib/modules unzugreifbar. Für diese
Einstellungen gelten die gleichen Einschränkungen bezüglich Einhängeausbreitung und Privilegien wie
für ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Beachten Sie, dass begrenztes automatisches
Modulladen aufgrund von Benutzerkonfiguration oder Kernelabbildungstabellen als Seiteneffekt von
angefragten Benutzeraktionen, sowohl privilegiert als auch unprivilegiert, weiterhin vorkommen kann.
Um die Funktionalität des automatischen Modulladens zu deaktivieren, lesen Sie bitte die
Dokumentation zum Mechanismus kernel.modules_disabled von sysctl.d(5) und
/proc/sys/kernel/modules_disabled. Falls dies eingeschaltet und im Benutzermodus oder im Systemmodus,
aber ohne die Capability CAP_SYS_ADMIN (z.B. durch Setzen von User=) betrieben wird, wird
NoNewPrivileges=yes impliziert.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
ProtectControlGroups=
Akzeptiert ein logisches Argument. Falls wahr, werden die über /sys/fs/cgroup erreichbaren »Linux
Control Groups« (cgroups(7))-Hierarchien für alle der Prozesse nur lesbar sein. Außer für
Container-Verwalter sollte kein Dienst Schreibzugriff auf diese Control-Gruppenhierarchie benötigen;
es wird daher empfohlen, dies für die meisten Dienste einzuschalten. Für diese Einstellungen gelten
die gleichen Einschränkungen bezüglich Einhängeausbreitung und Privilegien wie für ReadOnlyPaths= und
verwandte Aufrufe, siehe oben. Standardmäßig aus. Falls ProtectControlGroups= gesetzt ist, wird
MountAPIVFS=yes impliziert.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
RestrictAddressFamilies=
Beschränkt die Gruppe der Socket-Adressfamilien, auf die Prozesse dieser Unit zugreifen können.
Akzeptiert eine Leerzeichen-getrennte Liste von freizugebenden Adressfamiliennamen, wie AF_UNIX,
AF_INET oder AF_INET6. Wird dieser ~ vorangestellt, wird die Liste der Adressfamilien als
Ausschlussliste angewandt, andernfalls als Freigabeliste. Beachten Sie, dass dies nur Zugriff auf den
Systemaufruf socket(2) beschränkt. Sockets, die auf anderem Wege in die Unit hereingegeben werden
(beispielsweise durch Verwendung von Socket-Aktivierung mit Socket-Units, siehe systemd.socket(5))
sind davon nicht betroffen. Auch Sockets, die mit socketpair() (was nur verbundene AF_UNIX-Sockets
erstellt) erstellt werden, sind nicht betroffen. Beachten Sie, das diese Option keinen Effekt auf
32-Bit X86, S390, S390x, MIPS, MIPS-le, PPC, PPC-le, PCC64, PPC64-le hat und ignoriert wird
(funktioniert aber auf anderen ABIs, einschließlich x86-64, korrekt). Beachten Sie, dass auf
Systemen, die mehrere ABIs unterstützen (wie X86/X86-64), empfohlen wird, alternative ABIs für
Dienste zu deaktivieren, so dass sie nicht zur Umgehung der Einschränkungen dieser Option verwandt
werden können. Insbesondere wird empfohlen, diese Option mit SystemCallArchitectures=native oder
ähnlichem zu kombinieren. Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die
Capability CAP_SYS_ADMIN (z.B. durch Setzen von User=) erfolgt, wird NoNewPrivileges=yes impliziert.
Standardmäßig werden keine Einschränkungen angewandt, Prozesse können auf alle Adressfamilien
zugreifen. Falls die leere Zeichenkette zugewiesen wird, werden alle vorherigen Änderungen der
Einschränkung der Adressfamilie zurückgenommen. Diese Einstellung betrifft keine Befehle, denen »+«
vorangestellt sind.
Verwenden Sie diese Option, um den Kontakt des Prozesses für Zugriff aus der Ferne, insbesondere über
exotische und heikle Netzwerkprotokolle wie AF_PACKET, zu begrenzen. Beachten Sie, dass in den
meisten Fällen die lokale Adressfamilie AF_UNIX in die konfigurierte Freigabeliste aufgenommen werden
sollte, da sie häufig für lokale Kommunikation verwandt wird, einschließlich für die
syslog(2)-Protokollierung.
RestrictNamespaces=
Begrenzt Zugriff auf die Linux-Namensraumfunktionalität für die Prozesse dieser Unit. Für Details
über Linux-Namensräume siehe namespaces(7). Akzeptiert entweder ein logisches Argument oder eine
Leerraum-getrennte Liste von Namensraumtypkennzeichnern. Falls falsch (die Vorgabe), erfolgen keine
Beschränkungen bezüglich Namensraumerstellung und -umschaltung. Andernfalls muss eine
Leerzeichen-getrennte Liste von Namensraumtypkennzeichnern festgelegt werden, die aus einer
Kombination von cgroup, ipc, net, mnt, pid, user und uts bestehen. Jeder aufgeführte Namensraumtyp
wird den Prozessen der Unit zugreifbar gemacht, Zugriff auf nicht aufgeführte Namensräume sind
verboten (Freigabeliste). Durch Voranstellen des Tilde-Zeichens (»~«) kann der Effekt invertiert
werden: nur die aufgeführten Namensraumtypen werden nicht zugreifbar gemacht, alle nicht aufgeführten
sind erlaubt (Verbotsliste). Falls die leere Zeichenkette zugewiesen wird, werden die
Vorgabe-Namensraumeinschränkungen angewandt, was zu falsch äquivalent ist. Diese Option kann mehr als
einmal auftauchen. In diesem Fall werden die Namensraumtypen mit ODER (oder mit UND, falls den Zeilen
»~« vorangestellt wird) zusammengefasst (siehe nachfolgende Beispiele). Intern begrenzt diese
Einstellung Zugriff auf die Systemaufrufe unshare(2), clone(2) und setns(2) und berücksichtigt dabei
die festgelegten Schalterparameter. Beachten Sie, dass bei Verwendung dieser Option zusätzlich zur
Begrenzung der Erstellung und Umschaltung der festgelegten Namensraumtypen (oder allen von ihnen,
falls wahr) Zugriff auf den Systemaufruf setns() mit einem Nullschalterparameter verboten ist. Diese
Einstellung wird nur auf X86, X86-64, MIPS, MIPS-le, MIPS64, MIPS64-le, MIPS64-n32, MIPS64-le-n32,
PPC64, PPC64-le, S390 und S390x unterstützt und erwirkt auf anderen Architekturen keine
Einschränkungen. Falls der Betrieb im Benutzermodus oder im Systemmodus aber ohne die Capability
CAP_SYS_ADMIN (z.B. durch Setzen von User=) erfolgt, wird NoNewPrivileges=yes impliziert.
Beispiel: Falls eine Unit die Einstellunng
RestrictNamespaces=cgroup ipc
RestrictNamespaces=cgroup net
hat, dann werden cgroup, ipc und net gesetzt. Falls der zweiten Zeile »~« vorangestellt wird, d.h.
RestrictNamespaces=cgroup ipc
RestrictNamespaces=~cgroup net
dann wird nur ipc gesetzt.
LockPersonality=
Akzeptiert ein logisches Argument. Falls gesetzt, sperrt es den Systemaufruf personality(2), so dass
die Kernel-Ausführungsdomäne nicht mehr von der Vorgabe oder von der mit der Anweisung Personality=
ausgewählten Personalität geändert werden kann. Dies kann zur Verbesserung der Sicherheit nützlich
sein, da merkwürdige Personalitätsemulationen schlecht getestet und eine Quelle von Schwachstellen
sein können. Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability
CAP_SYS_ADMIN (z.B. durch Setzen von User=) erfolgt, wird NoNewPrivileges=yes impliziert.
MemoryDenyWriteExecute=
Takes a boolean argument. If set, attempts to create memory mappings that are writable and executable
at the same time, or to change existing memory mappings to become executable, or mapping shared
memory segments as executable are prohibited. Specifically, a system call filter is added that
rejects mmap(2) system calls with both PROT_EXEC and PROT_WRITE set, mprotect(2) or
pkey_mprotect(2) system calls with PROT_EXEC set and shmat(2) system calls with SHM_EXEC set. Note
that this option is incompatible with programs and libraries that generate program code dynamically
at runtime, including JIT execution engines, executable stacks, and code "trampoline" feature of
various C compilers. This option improves service security, as it makes harder for software exploits
to change running code dynamically. However, the protection can be circumvented, if the service can
write to a filesystem, which is not mounted with noexec (such as /dev/shm), or it can use
memfd_create(). This can be prevented by making such file systems inaccessible to the service (e.g.
InaccessiblePaths=/dev/shm) and installing further system call filters
(SystemCallFilter=~memfd_create). Note that this feature is fully available on x86-64, and partially
on x86. Specifically, the shmat() protection is not available on x86. Note that on systems supporting
multiple ABIs (such as x86/x86-64) it is recommended to turn off alternative ABIs for services, so
that they cannot be used to circumvent the restrictions of this option. Specifically, it is
recommended to combine this option with SystemCallArchitectures=native or similar. If running in user
mode, or in system mode, but without the CAP_SYS_ADMIN capability (e.g. setting User=),
NoNewPrivileges=yes is implied.
RestrictRealtime=
Akzeptiert ein logisches Argument. Falls gesetzt, werden alle Versuche, Echtzeit-Scheduling für einen
Prozess der Unit zu aktivieren, abgelehnt. Damit wird Zugriff auf die
Echtzeitprogramm-Scheduling-Richtlinien wie SCHED_FIFO, SCHED_RR oder SCHED_DEADLINE begrenzt. Siehe
sched(7) für Details über diese Scheduling-Richtlinien. Falls der Betrieb im Benutzermodus oder im
Systemmodus, aber ohne die Capability CAP_SYS_ADMIN (z.B. durch Setzen von User=) erfolgt, wird
NoNewPrivileges=yes impliziert. Echtzeit-Scheduling-Richtlinien können zur Monopolisierung von
CPU-Zeit für längere Zeitperioden verwandt werden und können daher dazu verwandt werden, das System
zu sperren oder anderweitige Diensteverweigerungssituationen auf dem System auszulösen. Es wird daher
empfohlen, den Zugriff auf Echtzeit-Scheduling auf die wenigen Programme, die dies tatsächlich
benötigen, zu begrenzen. Standardmäßig aus.
RestrictSUIDSGID=
Akzeptiert ein logisches Argument. Falls gesetzt, werden alle Versuche, die Bits »set-user-ID« (SUID)
oder »set-group-ID« (SGID) auf Dateien oder Verzeichnissen zu setzen, verweigert (für Details über
diese Bits siehe inode(7)).Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die
Capability CAP_SYS_ADMIN (z.B. durch Setzen von User=) erfolgt, wird NoNewPrivileges=yes impliziert.
Da SUID/SGID ein Mechanismus zur Erhöhung der Rechte ist und Benutzern erlaubt, die Identität anderer
Benutzer zu erlangen, wird empfohlen, die Erstellung von SUID/SGID-Dateien auf die wenigen Programme
zu beschränken, die dies tatsächlich benötigen. Beachten Sie, dass dies die Markierung jeder Art von
Dateisystemobjekt mit diesen Bits beschränkt, einschließlich regulärer Dateien und Verzeichnisse (auf
denen das Bit SGID eine andere Bedeutung als bei Dateien hat, siehe Dokumentation). Diese Option ist
impliziert, falls DynamicUser= aktiviert ist. Standardmäßig »off«.
RemoveIPC=
Akzeptiert ein logisches Argument. Falls gesetzt, werden alle System-V- und POSIX-IPC-Objekte, die
dem Benutzer und der Gruppe, unter der diese Unit läuft, gehören, entfernt, wenn die Unit gestoppt
wird. Diese Einstellung hat nur einen Effekt, falls eines aus User=, Group= oder DynamicUser=
verwandt wird. Es hat keinen Effekt für IPC-Objekte, die dem Benutzer »root« gehören. Insbesondere
entfernt dies System-V-Semaphoren sowie gemeinsam benutzte Segmente und Nachrichten-Warteschlangen
gemäß System V und POSIX. Falls mehrere Units die gleichen Benutzer oder Gruppen verwenden, werden
die IPC-Objekte entfernt, wenn die letzte dieser Units gestoppt wird. Diese Einstellung ist
impliziert, falls DynamicUser= gesetzt ist.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
PrivateMounts=
Akzeptiert einen logischen Parameter. Falls gesetzt, wird diese Unit in ihrem eigenen privaten
Dateisystem (Einhänge-)Namensraum betrieben, wobei alle Einhängeausbreitungen von dem Prozess in
Richtung des Hauptdateisystems des Rechners abgeschaltet sind. Dies bedeutet, dass alle vom Prozess
etablierten oder entfernten Dateisystemeinhängepunkte für diese privat und nicht im Hauptsystem
sichtbar sind. Allerdings werden Dateisystemeinhängepunkte, die auf dem System etabliert oder
entfernt werden, sich zu den Prozessen der Unit ausbreiten. Siehe mount_namespaces(7) für Details
bezüglich Dateisystemnamensräumen. Standardmäßig aus.
Falls eingeschaltet, wird dies drei Aktionen für jeden aufgerufenen Prozess auslösen: ein neuer
CLONE_NEWNS-Namensraum wird erstellt, danach werden alle existierenden Einhängungen neu als MS_SLAVE
eingehängt, um die Ausbreitung aus den Prozessen der Unit zu dem Hauptsystem zu deaktivieren (aber
die Ausbreitung in die umgekehrte Richtung bleibt wirksam). Schließlich werden die Einhängungen
erneut gemäß des in dem Schalter MountFlags= konfigurierten Ausbreitungsmodus eingehängt, siehe
unten.
Dateisystemnamensräume werden individuell für jeden mit »fork« vom Diensteverwalter gestarteten
Prozess eingerichtet. Einhängungen, die im Namensraum des durch ExecStartPre= erstellten Prozesses
etabliert wurden, werden daher automatisch bereinigt, sobald der Prozess sich beendet und werden für
nachfolgend durch ExecStart= mit Fork gestartete Prozesse nicht verfügbar sein (und Ähnliches gilt
auch für die verschiedenen anderen für Units konfigurierten Befehle). Ähnlich erlaubt
JoinsNamespaceOf= nicht die gemeinsame Benutzung von Kernelnamensräumen zwischen Units, es ermöglicht
nur die gemeinsame Benutzung der Verzeichnisse /tmp/ und /var/tmp/.
Andere Dateisystemnamensräume-Einstellungen für Units — PrivateMounts=, PrivateTmp=, PrivateDevices=,
ProtectSystem=, ProtectHome=, ReadOnlyPaths=, InaccessiblePaths=, ReadWritePaths=, … — ermöglichen
Dateisystemnamensräume in einer Art ähnlich dieser Option. Daher ist es primär zur expliziten Anfrage
dieses Verhalten nützlich, falls keine der anderen Einstellungen verwandt wird.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
MountFlags=
Akzeptiert eine Einhängeausbreitungseinstellung: shared, slave oder private, die steuert, ob
Dateisystemeinhängepunkte, die für die Prozesse dieser Unit in dem Dateisystemnamensraum eingerichtet
wurden, Einhängungen oder Aushängungen aus anderen Dateisystemnamensräumen empfangen oder ausbreiten.
Siehe mount(2) für Details über Einhängeausbreitungen und insbesondere die drei Ausbreitungsschalter.
Diese Einstellung steuert nur die abschließenden Ausbreitungseinstellungen, die für alle
Einhängepunkte des Dateisystemnamensraums, der für jeden Prozess dieser Unit erstellt wurde, wirksam
sind. Andere Dateisystemnamensraum-Unit-Einstellungen (siehe die Diskussion in PrivateMounts= oben)
werden implizit Einhänge- und Aushängeausbreitung von den Prozessen der Unit in Richtung des Systems
deaktivieren, indem sie die Ausbreitungseinstellungen aller Einhängepunkte in dem
Dateisystemnamensraum der Unit zuerst auf slave setzen. Setzen der Option auf shared richtet die
Ausbreitung in diesem Fall nicht wieder ein.
Falls nicht gesetzt – aber es sind durch andere Dateisystemnamensraumeinstellungen der Unit keine
Dateisystemnamensräume aktiviert –, wird shared Einhängeausbreitung verwandt, aber wie erwähnt, wird
slave zuerst angewandt, Ausbreitung von den Prozessen der Unit zum Hauptsystem bleibt weiterhin
abgeschaltet.
Es wird nicht empfohlen, private Einhängeausbreitung für Units zu verwenden, da dies bedeutet, dass
temporäre Einhängungen (wie Wechselmedien) auf dem Hauptsystem eingehängt bleiben und daher
unbefristet in mit Fork erstellten Programmen als beschäftigt markiert sind, da die
Aushängeausbreitungsereignisse in dem Dateisystemnamensraum der Unit nicht empfangen werden.
Normalerweise ist es am besten, diese Einstellung unverändert zu lassen und stattdessen abstraktere
Dateisystemnamensraumoptionen zu verwenden, insbesondere PrivateMounts=, siehe oben.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in
benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
SYSTEMAUFRUFFILTERUNG
SystemCallFilter=
Akzeptiert eine Leerzeichen-getrennte Liste von Systemaufrufenamen. Falls diese Einstellung verwandt
wird, werden alle Systemaufrufe, die durch die Prozesse der Unit ausgeführt werden, zu sofortiger
Beendigung mit dem Signal SIGSYS führen, falls sie nicht aufgeführt sind (Freigabeliste). (Siehe
SystemCallErrorNumber= zur Änderung der Standardaktion). Falls das erste Zeichen der Liste »~« ist,
wird die Wirkung invertiert: nur die aufgeführten Systemaufrufe führen zu einer sofortigen
Prozessbeendigung (Verbotsliste). Freigegebenen Systemaufrufen und Systemaufrufgruppen kann optional
ein Doppelpunkt (»:«) und »errno«-Fehlernummern (zwischen 0 und 4095) oder Fehlernummernamen wie
EPERM, EACCES oder EUCLEAN (siehe errno(3) für eine komplette Liste) angehängt werden. Dieser Wert
wird zurückgeliefert, wenn ein verbotener Systemaufruf ausgelöst wird, statt den Prozess sofort zu
beenden. Dieser Wert hat vor dem in SystemCallErrorNumber= angegebenen Vorrang, siehe unten. Falls
der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability CAP_SYS_ADMIN (z.B. durch
Setzen von User=nobody) erfolgt, wird NoNewPrivileges=yes impliziert. Diese Funktionalität verwendet
die Schnittstelle »Secure Computing Mode 2« des Kernels (»Seccomp-Filterung«) und ist nützlich, um
eine minimale Sandboxing-Umgebung zu erzwingen. Beachten Sie, dass die Systemaufrufe execve, exit,
exit_group, getrlimit, rt_sigreturn, sigreturn und die Systemaufrufe zur Abfrage der Zeit und zum
Schlafen implizit auf der Freigabeliste sind und nicht explizit aufgelistet werden müssen. Diese
Option kann mehr als einmal angegeben werden, die Filtermasken werden in diesem Fall zusammengeführt.
Falls die leere Zeichenkette zugewiesen wird, wird der Filter zurückgesetzt und alle vorherigen
Zuweisungen haben keine Wirkung. Diese betrifft Befehle, denen »+« vorangestellt ist, nicht.
Beachten Sie, dass auf Systemen, die mehrere ABIs unterstützen (wie X86/X86-64), empfohlen wird,
alternative ABIs für Dienste zu deaktivieren, so dass sie nicht zur Umgehung der Einschränkungen
dieser Option verwandt werden können. Insbesondere wird empfohlen, diese Option mit
SystemCallArchitectures=native oder Ähnlichem zu kombinieren.
Beachten Sie, dass strenge Systemaufruffilterung die Ausführungs- und Fehlerbehandlungs-Code-Pfade
des Diensteaufrufs beeinflussen können. Insbesondere wird der Zugriff auf den Systemaufruf execve für
die Ausführung des Diensteprogrammes benutzt — falls er blockiert ist, wird der Diensteaufruf
notwendigerweise fehlschlagen. Falls auch die Ausführung des Diensteprogramms aus irgendwelchen
Gründen fehlschlägt (beispielsweise fehlendes Diensteprogramm), könnte die Fehlerbehandlungslogik
Zugriff auf eine zusätzliche Gruppe an Systemaufrufen benötigen, um diesen Fehlschlag korrekt zu
verarbeiten und zu protokollieren. Es könnte notwendig sein, temporär die Systemaufruffilter zu
deaktivieren, um die Fehlersuche bei solchen Fehlschlägen zu vereinfachen.
Falls Sie beide Arten dieser Option (d.h. explizite Freischaltung und Ausschlussliste) festlegen,
wird die erste angetroffene Vorrang haben und die Standardaktion festlegen (Beendigung oder
Bestätigung eines Systemaufrufs). Dann wird das nächste Auftreten dieser Option die Liste der
Systemaufrufe zu der Menge der gefilterten Systemaufrufe hinzufügen oder aus dieser löschen, abhängig
von seiner Art und der Standardaktion. (Falls Sie beispielsweise mit einer expliziten Freischaltung
von read und write beginnen und direkt danach eine Ausschlussliste mit write hinzufügen, dann wird
write aus der Menge entfernt.)
Da die Anzahl der möglichen Systemaufrufe groß ist, werden vordefinierte Gruppen von Systemaufrufen
bereitgestellt. Eine Gruppe beginnt mit dem Zeichen »@«, gefolgt vom Namen der Gruppe.
Tabelle 3. Derzeit vordefinierte Systemaufrufgruppen
┌─────────────────┬───────────────────────────────────────┐
│ Gruppe │ Beschreibung │
├─────────────────┼───────────────────────────────────────┤
│ @aio │ Asynchrone E/A (io_setup(2), │
│ │ io_submit(2) und verwandte Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @basic-io │ Systemaufrufe für grundlegende E/A: │
│ │ Lesen, Schreiben, Suchen, Duplizieren │
│ │ und Schließen von Dateideskriptoren │
│ │ (read(2), write(2) und verwandte │
│ │ Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @chown │ Änderung der Dateieigentümerschaft │
│ │ (chown(2), fchownat(2) und verwandte │
│ │ Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @clock │ Systemaufrufe zur Änderung der │
│ │ Systemuhr (adjtimex(2), │
│ │ settimeofday(2) und verwandte │
│ │ Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @cpu-emulation │ Systemaufrufe für │
│ │ CPU-Emulierungsfunktionen (vm86(2) │
│ │ und verwandte Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @debug │ Fehlersuche, Leistungsüberwachung und │
│ │ Nachverfolgungsfunktionen (ptrace(2), │
│ │ perf_event_open(2) und verwandte │
│ │ Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @file-system │ Dateisystemaktionen: Öffnen, Dateien │
│ │ und Verzeichnisse zum Lesen und │
│ │ Schreiben erstellen, sie umbenennen │
│ │ oder entfernen, Lesen von │
│ │ Dateieigenschaften oder Erstellen von │
│ │ harten und symbolischen Links │
├─────────────────┼───────────────────────────────────────┤
│ @io-event │ Systemaufrufe für Ereignisschleifen │
│ │ (poll(2), select(2), epoll(7), │
│ │ eventfd(2) und verwandte Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @ipc │ Pipes, SysV IPC, │
│ │ POSIX-Nachrichtenwarteschlangen und │
│ │ andere IPC (mq_overview(7), svipc(7)) │
├─────────────────┼───────────────────────────────────────┤
│ @keyring │ Kernel-Schlüsselbundzugriff │
│ │ (keyctl(2) und verwandte Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @memlock │ Sperren von Speicher im RAM │
│ │ (mlock(2), mlockall(2) und verwandte │
│ │ Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @module │ Laden und Entladen von Kernelmodulen │
│ │ (init_module(2), delete_module(2) und │
│ │ verwandte Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @mount │ Einhängen und Aushängen von │
│ │ Dateisystemen (mount(2), chroot(2) │
│ │ und verwandte Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @network-io │ Socket-E/A (einschließlich lokalem │
│ │ AF_UNIX): socket(7), unix(7) │
├─────────────────┼───────────────────────────────────────┤
│ @obsolete │ Ungewöhnliches, Veraltetes oder nicht │
│ │ Implementiertes (create_module(2), │
│ │ gtty(2), …) │
├─────────────────┼───────────────────────────────────────┤
│ @privileged │ Alle Systemaufrufe, die │
│ │ Administrator-Capabilities benötigen │
│ │ (capabilities(7)) │
├─────────────────┼───────────────────────────────────────┤
│ @process │ Prozesssteuerung, -ausführung, │
│ │ Namensraumaktionen (clone(2), │
│ │ kill(2), namespaces(7), …) │
├─────────────────┼───────────────────────────────────────┤
│ @raw-io │ Rohzugriff auf E/A-Ports (ioperm(2), │
│ │ iopl(2), pciconfig_read(), …) │
├─────────────────┼───────────────────────────────────────┤
│ @reboot │ Systemaufrufe für den Neustart und │
│ │ die Neustartvorbereitung (reboot(2), │
│ │ kexec(), …) │
├─────────────────┼───────────────────────────────────────┤
│ @resources │ Systemaufrufe für die Änderung von │
│ │ Ressourcenbeschränkungen, Speicher- │
│ │ und Schedulingparametern │
│ │ (setrlimit(2), setpriority(2), …) │
├─────────────────┼───────────────────────────────────────┤
│ @setuid │ Systemaufrufe zur Änderung der │
│ │ Benutzerkennung und │
│ │ Gruppenberechtigungen (setuid(2), │
│ │ setgid(2), setresuid(2), …) │
├─────────────────┼───────────────────────────────────────┤
│ @signal │ Systemaufrufe für die Veränderung und │
│ │ Handhabung von Prozesssignalen │
│ │ (signal(2), sigprocmask(2), …) │
├─────────────────┼───────────────────────────────────────┤
│ @swap │ Systemaufrufe für die │
│ │ Aktivierung/Deaktivierung von │
│ │ Auslagerungsgeräten (swapon(2), │
│ │ swapoff(2)) │
├─────────────────┼───────────────────────────────────────┤
│ @sync │ Synchronisierung von Dateien und │
│ │ Speicher auf Platte: (fsync(2), │
│ │ msync(2) und verwandte Aufrufe) │
├─────────────────┼───────────────────────────────────────┤
│ @system-service │ Eine vernünftige Gruppe von │
│ │ Systemaufrufen, die von typischen │
│ │ Systemdiensten benutzt werden, │
│ │ ausschließlich aller Systemaufrufe │
│ │ für besondere Zwecke. Dies ist der │
│ │ empfohlene Anfangspunkt zum │
│ │ expliziten Erlauben von │
│ │ Systemaufrufen für Systemdienste, da │
│ │ es das enthält, was typischerweise │
│ │ von Systemdiensten benötigt wird, │
│ │ aber äußerst spezielle Schnittstellen │
│ │ ausschließt. Beispielsweise sind die │
│ │ folgenden APIs ausgeschlossen: │
│ │ »@clock«, »@mount«, »@swap«, │
│ │ »@reboot«. │
├─────────────────┼───────────────────────────────────────┤
│ @timer │ Systemaufrufe für Scheduling-Aktionen │
│ │ von Time (alarm(2), timer_create(2), │
│ │ …) │
└─────────────────┴───────────────────────────────────────┘
Beachten Sie, dass neue Systemaufrufe zu den obigen Gruppen hinzugefügt werden könnten, wenn neue
Systemaufrufe zu dem Kernel hinzugefügt werden. Die Inhalte dieser Gruppen können sich auch zwischen
Systemd-Versionen unterscheiden. Zusätzlich hängt die Liste der Systemaufrufe auch von der
Kernelversion und der Architektur, für die Systemd kompiliert wurde, ab. Verwenden Sie
systemd-analyze syscall-filter, um die tatsächliche Liste der Systemaufrufe in jedem Filter
aufzuführen.
Im Allgemeinen ist das explizite Erlauben von Systemaufrufen (statt einer Ausschlussliste) der
sicherere Betriebsmodus. Es wird empfohlen, für alle langlaufenden Systemdienste eine Liste explizit
erlaubter Systemaufrufe zu erzwingen. Insbesondere sind die nachfolgenden Zeilen eine relativ
sicherere grundlegende Wahl für den Großteil der Systemdienste:
[Service]
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
Beachten Sie, dass die verschiedenen Systemaufrufe redundant definiert werden: es gibt mehrere
Systemaufrufe zur Ausführung der gleichen Aktion. Beispielsweise kann der Systemaufruf
pidfd_send_signal() zur Ausführung von Aktionen ähnlich zu dem älteren Systemaufruf kill() verwandt
werden, daher führt das Blockieren von letzterem ohne das Blockieren des ersteren nur zu einem
schwachen Schutz. Da neue Systemaufrufe regelmäßig dem Kernel hinzugefügt werden, verlangt das
Pflegen von vollständigen Ausschlusslisten für Systemaufrufe ständige Arbeit. Es wird daher
empfohlen, stattdessen Freischaltungen einzusetzen, wodurch der Nutzen entsteht, dass neue
Systemaufrufe standardmäßig implizit blockiert sind, bis die Freischaltung aktualisiert wurde.
Beachten Sie auch, dass eine Reihe von Systemaufrufen zugreifbar sein müssen, damit der dynamische
Linker funktioniert. Der dynamische Linker wird zur Ausführung der meisten regulären Programme
benötigt (konkret dynamische ELF-Programme - auf diese Art bauen die meisten Distributionen
paketierte Programme). Dies bedeutet, dass das Blockieren dieser Systemaufrufe (wozu open(), openat()
und mmap() gehören) dazu führen wird, das die meisten mit generischen Distributionen ausgelieferten
Programme unbenutzbar werden.
Es wird empfohlen, die auf den Namensraum des Dateisystems bezogenen Optionen mit
SystemCallFilter=~@mount zu kombinieren, um zu verhindern, dass die Prozesse der Unit die Abbildungen
rückgängig machen. Insbesondere sind dies die Optionen PrivateTmp=, PrivateDevices=, ProtectSystem=,
ProtectHome=, ProtectKernelTunables=, ProtectControlGroups=, ReadOnlyPaths=, InaccessiblePaths= und
ReadWritePaths=.
SystemCallErrorNumber=
Akzeptiert eine »errno«-Fehlernummer (zwischen 1 und 4095) oder einen Errno-Namen wie EPERM, EACCES
oder EUCLEAN, der zurückgeliefert werden soll, wenn der mit SystemCallFilter= konfigurierte
Systemaufruffilter ausgelöst wird, statt den Prozess sofort zu beenden. Siehe errno(3) für eine
vollständige Liste der Fehlercodes. Wenn diese Einstellung nicht benutzt wird, oder wenn ihm die
leere Zeichenkette zugewiesen wird, wird der Prozess sofort beendet, wenn der Filter ausgelöst wird.
SystemCallArchitectures=
Akzeptiert eine Leerzeichen-getrennte Liste von Architekturkennungen, die in den Systemaufrufilter
einbezogen werden sollen. Die bekannten Architekturkennungen sind die gleichen wie für das in
systemd.unit(5) beschriebene ConditionArchitecture=, sowie x32, mips64-n32, mips64-le-n32 und die
besondere Kennung native. Die besondere Kennung native wird implizit auf die native Architektur des
Systems abgebildet (oder genauer: auf die Architektur, für die der Systemverwalter kompiliert wurde).
Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability CAP_SYS_ADMIN (z.B.
durch Setzen von User=) erfolgt, wird NoNewPrivileges=yes impliziert. Standardmäßig wird diese Option
auf die leere Liste gesetzt, d.h. keine Systemaufrufarchitekturfilterung erfolgt.
Falls diese Einstellung verwandt wird, wird den Prozessen dieser Unit nur der Aufruf nativer
Systemaufrufe und von Systemaufrufen der festgelegten Architektur erlaubt. Für die Zwecke dieser
Option wird die Architektur X32 so behandelt, dass sie die Systemaufrufe von X86-64 enthält.
Allerdings erfüllt diese Einstellung auf X32 weiterhin ihren Zweck, wie unten dargestellt.
Systemaufruffilterung ist nicht auf allen Architekturen wirksam. Beispielsweise ist auf X86 aufgrund
von ABI-Einschränkungen das Filtern von Netz-Socket-bezogenen Aufrufen nicht möglich, eine
Einschränkung, die X86-64 allerdings nicht hat. Auf Systemen, die mehrere ABI gleichzeitig
unterstützen, wie X86/X86-64, wird daher empfohlen, die Gruppe der erlaubten
Systemaufrufarchitekturen einzuschränken, so dass das sekundäre ABI nicht dazu verwandt werden kann,
die dem nativen ABI des Systems auferlegten Einschränkungen zu umgehen. Insbesondere ist das Setzen
von SystemCallArchitectures=native für das Deaktivieren nichtnativer ABIs eine gute Wahl.
Systemaufrufarchitekturen können auch systemweit mittels der Option SystemCallArchitectures= in der
globalen Konfiguration eingeschränkt werden. Siehe systemd-system.conf(5) für Details.
UMGEBUNGSVARIABLEN
Environment=
Setzt Umgebungsvariablen für ausgeführte Prozesse. Akzeptiert eine Leerzeichen-getrennte Liste von
Variablenzuweisungen. Diese Option kann mehr als einmal festgelegt werden, dann werden alle
aufgeführten Variablen gesetzt. Falls die gleiche Variable zweimal gesetzt ist, wird die spätere
Einstellung die frühere Einstellung außer Kraft setzen. Falls der Option die leere Zeichenkette
zugewiesen wird, wird die Liste der Umgebungsvariablen zurückgesetzt und alle vorhergehenden
Zuweisungen haben keine Wirkung. Innerhalb der Zeichenkette wird keine Variablenexpansion
durchgeführt, es ist allerdings eine Kennzeichner-Expansion möglich. Das Zeichen $ hat keine
besondere Bedeutung. Falls Sie einen Wert, der Leerzeichen oder Gleichheitszeichen enthält, einer
Variablen zuweisen müssen, verwenden Sie doppelte Anführungszeichen (") für die Zuweisung.
Beispiel:
Environment="VAR1=Wort1 Wort2" VAR2=Wort3 "VAR3=$Wort 5 6"
ergibt drei Variablen »VAR1«, »VAR2«, »VAR3« mit den Werten »Wort1 Wort2«, »Wort3«, »$Wort 5 6«.
Siehe environ(7) für Details über Umgebungsvariablen.
Beachten Sie, dass Umgebungsvariablen nicht dazu geeignet sind, Geheimnisse (wie Passwörter,
Schlüsselmaterial, …) an Diensteprozesse weiterzugeben. Für eine Unit gesetzte Umgebungsvariablen
können von nicht privilegierten Clients wie D-Bus-IPC eingesehen werden und werden im Allgemeinen
nicht als Daten betrachtet, die geschützt werden müssen. Desweiteren werden Umgebungsvariablen den
Prozessbaum heruntergereicht, auch über Sicherheitsgrenzen (wie Setuid/Setgid-Programme) hinweg und
könnten daher zu Prozessen durchsickern, die keinen Zugriff auf die geheimen Daten haben sollen.
EnvironmentFile=
Ähnlich zu Environment=, liest aber die Umgebungsvariablen aus einer Textdatei. Die Textdatei sollte
durch Zeilenumbrüche getrennte Variablenzuweisungen enthalten. Leere Zeilen, Zeilen ohne einen
»=«-Trenner und Zeilen, die mit ; oder # beginnen, werden ignoriert. Letzteres kann zur Kommentierung
verwandt werden. Eine Zeile, die mit einem Rückwärtsschrägstrich endet, wird mit der nachfolgenden
verbunden, wodurch mehrzeilige Variablendefinitionen ermöglicht werden. Das Auswertprogramm entfernt
Leerraumzeichen am Anfang und Ende der Zeile von den Werten der Zuweisungen, falls Sie keine
doppelten Anführungszeichen (") verwenden.
Das übergebene Argument sollte ein absoluter Dateiname oder ein Platzhalterausdruck sein, dem
optional »-« vorangestellt werden kann, um anzuzeigen, dass sie nicht gelesen werden soll und keine
Fehler- oder Warnmeldung protokolliert wird, falls sie nicht existiert. Diese Option kann mehr als
einmal festgelegt werden, in diesem Fall werden alle festgelegten Dateien gelesen. Falls der Option
die leere Zeichenkette zugewiesen wird, wird die Liste der zu lesenden Dateien zurückgesetzt und alle
vorherigen Zuweisungen haben keine Wirkung.
Die mit dieser Anweisung aufgeführten Dateien werden kurz vor der Ausführung des Prozesses gelesen
(genauer gesagt, nachdem alle Prozesse eines vorherigen Unit-Zustandes beendet wurden. Dies bedeutet,
dass Sie diese Dateien in einem Unit-Zustand erstellen und sie mit dieser Option in dem nächsten
lesen können).
Einstellungen von diesen Dateien setzen mit Environment= vorgenommene Einstellungen außer Kraft.
Falls die gleiche Variable zweimal von diesen Dateien gesetzt wird, werden die Dateien in der
festgelegten Reihenfolge eingelesen und spätere Einstellungen werden die früheren Einstellungen außer
Kraft setzen.
PassEnvironment=
Übergibt für den Diensteverwalter gesetzte Umgebungsvariablen an ausgeführte Prozesse. Akzeptiert
eine Leerzeichen-getrennte Liste von Variablennamen. Diese Option kann mehr als einmal angegeben
werden, dann werden alle aufgeführten Variablen übergeben. Falls dieser Option die leere Zeichenkette
zugewiesen wird, wird die Liste der zu übergebenden Umgebungsvariablen zurückgesetzt, alle vorherigen
Zuweisungen haben keine Wirkung. Festgelegte Variablen, die für den Systemverwalter nicht gesetzt
sind, werden nicht übergeben und werden ohne Rückmeldung ignoriert. Beachten Sie, dass diese Option
nur für den Systemdiensteverwalter relevant ist, da Systemdienste standardmäßig keine
Umgebungsvariablen, die für den Diensteverwalter gesetzt sind, erben. Im Falle des
Benutzerdiensteverwalters werden alle Umgebungsvariablen sowieso an den ausgeführten Prozess
übergeben, daher hat diese Option für Benutzerdiensteverwalter keine Wirkung.
Variablen, die aufgrund dieser Einstellung für aufgerufene Prozesse gesetzt werden, könnten durch
solche, die mit Environment= oder EnvironmentFile= konfiguriert wurden, außer Kraft gesetzt zu
werden.
Beispiel:
PassEnvironment=VAR1 VAR2 VAR3
übergibt die drei Variablen »VAR1«, »VAR2«, »VAR3« mit den für diese Variablen in PID1 gesetzten
Werten.
Siehe environ(7) für Details über Umgebungsvariablen.
UnsetEnvironment=
Setzt die Variablenzuweisungen, die normalerweise von dem Diensteverwalter an den aufgerufenen
Prozess dieser Unit weitergegeben würden, zurück. Akzeptiert eine Lerraum-getrennte Liste von
Variablennamen oder Variablenzuweisungen. Diese Option kann mehr als einmal angegeben werden, dann
werden alle aufgeführten Variablen/Zuweisungen zurückgesetzt. Falls der Option die leere Zeichenkette
zugewiesen wird, wird die Liste der Umgebungsvariablen/Zuweisungen, die zurückgesetzt werden sollen,
zurückgesetzt. Falls eine Variablenzuweisung festgelegt ist (das heißt: einem Variablennamen, dem ein
»=« und sein Wert folgt), dann wird jede Umgebungsvariable, die exakt auf diese Zuweisung passt,
entfernt. Falls ein Variablennname festgelegt ist (das ist ein Variablenname, dem kein »=« oder ein
Wert folgt), dann wird jede Zuweisung, die auf diesen Variablennamen passt, entfernt, unabhängig von
dessen Wert. Beachten Sie, dass die Wirkung von UnsetEnvironment= als abschließender Schritt
angewandt wird, wenn die an den auszuführenden Prozess zu übergebende Umgebungsliste zusammengestellt
wird. Das bedeutet, dass es Zuweisungen von jeder Konfigurationsquelle rückgängig machen könnte,
einschließlich Zuweisungen, die mittels Environment= oder EnvironmentFile= erfolgten, die von der
globalen Menge der Umgebungsvariablen des Systemverwalters geerbt wurden, die vom Diensteverwalter
selbst gesetzt wurden (wie $NOTIFY_SOCKET und ähnliche) oder die durch ein PAM-Modul gesetzt wurden
(falls PAMName= benutzt wird).
Siehe environ(7) für Details über Umgebungsvariablen.
PROTOKOLLIERUNG UND SYSTEM-EIN-/-AUSGABE
StandardInput=
Steuert, womit der Dateideskriptor 0 (STDIN) des ausgeführten Prozesses verbunden ist. Akzeptiert
null, tty, tty-force, tty-fail, data, file:Pfad, socket oder fd:Name.
Falls null ausgewählt wird, wird die Standardeingabe mit /dev/null verbunden, d.h. alle Leseversuche
durch den Prozess werden sofort zu einem EOF führen.
Falls tty ausgewählt ist, wird die Standardeingabe mit einem TTY (wie mit TTYPath= konfiguriert,
siehe unten) verbunden und der ausgeführte Prozess wird der steuernde Prozess des Terminals. Falls
das Terminal bereits durch einen anderen Prozess gesteuert wird, wartet der ausgeführte Prozess, bis
der derzeit steuernde Prozess das Terminal freigibt.
tty-force ist ähnlich zu tty, der ausgeführte Prozess wird aber zwangsweise und sofort zum steuernden
Prozess des Terminals gemacht, möglicherweise werden dabei vorhergehende steuernde Prozesse von dem
Terminal entfernt.
tty-fail ist ähnlich zu tty, falls aber das Terminal bereits einen steuernden Prozess hat, schlägt
das Hochfahren des ausgeführten Prozesses fehl.
Die Option data kann zur Konfiguration beliebiger textueller oder binärer Daten, die mittels
Standardeingabe an den ausgeführten Prozess übergeben werden sollen, verwandt werden. Die zu
übergebenden Daten werden mittels StandardInputText=/StandardInputData= (siehe unten) konfiguriert.
Beachten Sie, dass der tatsächlich übergebene Dateideskriptortyp (Speicherdatei, reguläre Datei,
UNIX-Pipe, …) vom Kernel und den verfügbaren Privilegien abhängen könnte. Auf jeden Fall ist der
Dateideskriptor nur lesbar und er liefert die festgelegten Daten, gefolgt von EOF, zurück, wenn er
gelesen wird.
Die Option file:Pfad kann zur Verbindung der Standardeingabe mit einem bestimmten Dateisystemobjekt
verwandt werden. Es wird ein absoluter Pfad gefolgt von dem Zeichen »:« erwartet, der sich auf eine
reguläre Datei, ein FIFO oder eine Spezialdatei beziehen kann. Falls ein AF_UNIX-Socket in dem
Dateisystem festgelegt ist, wird mit ihm ein Datenstrom-Socket verbunden. Letzteres ist nützlich, um
die Standardeingabe eines beliebigen Prozesses mit einem beliebigen Systemdienst zu verbinden.
Die Option »socket« ist nur in Socket-aktivierten Diensten gültig und es muss in der relevanten
Socket-Unit-Datei (siehe systemd.socket(5) für Details) Accept=yes gesetzt oder nur ein einzelnes
Socket spezifiziert sein. Falls diese Option gesetzt ist, wird die Standardeingabe mit dem Socket,
aus dem der Dienst aktiviert wurde, verbunden. Dies ist hauptsächlich für die Kompatibilität mit
Daemons nützlich, die für die Verwendung mit der traditionellen inetd(8)-Socket-Daemon-Aktivierung
entwickelt wurden.
Die Option fd:Name verbindet die Standardeingabe mit einem durch die Socket-Unit bereitgestellten
bestimmten, benannten Dateideskriptor. Der Name kann als Teil dieser Option festgelegt werden,
gefolgt vom Zeichen »:« (z.B. »fd:foobar«). Falls kein Name festgelegt ist, wird der Name »stdin«
impliziert (d.h. »fd« ist äquivalent zu »fd:stdin«). Mindestens eine Socket-Unit, die den
festgelegten Namen definiert, muss über die Option Sockets= bereitgestellt werden und der
Dateideskriptorname darf sich vom Namen der Socket-Unit, die ihn enthält, unterscheiden. Falls
mehrere Treffer gefunden werden, wird der erste verwandt. Siehe FileDescriptorName= in
systemd.socket(5) für weitere Details über benannte Dateideskriptoren und ihrer Sortierung.
Diese Einstellung ist standardmäßig null.
Beachten Sie, dass Dienste, die DefaultDependencies=no festlegen und StandardInput= oder
StandardOutput= mit tty/tty-force/tty-fail verwenden, After=systemd-vconsole-setup.service festlegen
sollten, um sicherzustellen, dass die TTY-Initialisierung abgeschlossen ist, bevor sie starten.
StandardOutput=
Steuert, womit der Dateideskriptor 1 (STDOUT) des ausgeführten Prozesses verbunden ist. Akzeptiert
entweder inherit, null, tty, journal, kmsg, journal+console, kmsg+console, file:Pfad, append:Pfad,
socket oder fd:Name.
inherit dupliziert den Dateideskriptor der Standardeingabe für die Standardausgabe.
null verbindet die Standardausgabe mit /dev/null, d.h. alles dahin Geschriebene geht verloren.
tty verbindet die Standardausgabe mit einem TTY (wie in TTYPath= konfiguriert, siehe unten). Falls
das TTY nur für die Ausgabe verwandt wird, wird der ausgeführte Prozess nicht der steuernde Prozess
des Terminals werden und wird nicht fehlschlagen oder darauf warten, dass andere Prozesse das
Terminal freigeben.
journal verbindet die Standardausgabe mit dem Journal, das über journalctl(1) erreichbar ist.
Beachten Sie, dass alles, was nach Syslog oder Kmsg (siehe unten) geschrieben wird, implizit auch im
Journal gespeichert wird, die spezielle unten aufgeführten Optionen ist daher eine Obermenge dieser
Option. (Beachten Sie auch, dass alle externen, zusätzlichen Syslog-Deamons ihre Protokolldaten auch
aus dem Journal empfangen, daher ist dies die Option, die verwandt werden sollte, wenn das Protokoll
mit solch einem Daemon verarbeitet werden soll.)
kmsg verbindet die Standardeingabe mit dem Kernelprotokollpuffer, der über dmesg(1) erreichbar ist,
zusätzlich zum Journal. Der Journal-Daemon könnte so konfiguriert sein, dass er alles, was er
empfängt, sowieso zu Kmsg sendet, wodurch diese Option in diesem Fall keinen Unterschied zu journal
darstellt.
journal+console und kmsg+console arbeiten auf eine ähnliche Art wie die zwei Optionen oben, kopieren
aber auch sämtliche Ausgabe auf die Systemkonsole.
Die Option file:Pfad kann zum Verbinden eines bestimmten Dateisystemobjektes mit der Standardausgabe
verwandt werden. Die Semantik ist ähnlich zu der der gleichen Option von StandardInput=, siehe oben.
Falls sich Pfad auf eine reguläre Datei auf dem Dateisystem bezieht, wird sie zum Schreiben am Anfang
der Datei geöffnet (erstellt, falls sie noch nicht existiert), aber ohne sie abzuschneiden. Falls die
Standardeingabe und -ausgabe auf den gleichen Dateipfad verwiesen werden, wird dieser nur einmal zum
Lesen und Schreiben geöffnet und dupliziert. Dies ist insbesondere nützlich, wenn sich der
festgelegte Pfad auf ein AF_UNIX-Socket im Dateisystem bezieht, da in diesem Fall nur eine einzelne
Datenstromverbindung für sowohl Ein- als auch Ausgabe erstellt wird.
append:Pfad ist ähnlich zu file:Pfad oben, es öffnet die Datei aber im Anhängemodus.
socket verbindet die Standardausgabe zu einem mittels Socket-Aktivierung erlangten Socket. Die
Semantik ist ähnlich zu der der gleichen Option von StandardInput=, siehe oben.
Die Option fd:Name verbindet die Standardausgabe mit einem bestimmten benannten, durch eine
Socket-Unit bereitgestellten Dateideskriptor. Es kann als Teil dieser Option ein Name, gefolgt von
einem »:«-Zeichen, festgelegt werden (z.B. »fd:foobar«). Falls kein Name festgelegt ist, wird der
Name »stdout« impliziert (d.h. »fd« ist äquivalent zu »fd:stdout«). Mindestens eine Socket-Unit, die
den festgelegten Namen definiert, muss über die Option Sockets= bereitgestellt werden und der
Dateideskriptorname darf sich vom Namen der Socket-Unit, die ihn enthält, unterscheiden. Falls
mehrere Treffer gefunden werden, wird der erste verwandt. Siehe FileDescriptorName= in
systemd.socket(5) für weitere Details über benannte Dateideskriptoren und ihrer Sortierung.
Falls die Standardausgabe (oder die Fehlerausgabe, siehe unten) einer Unit mit dem Journal oder dem
Kernelprotokollpuffer verbunden ist, wird die Unit implizit eine Abhängigkeit vom Typ After= von
systemd-journald.socket erhalten (siehe auch den Abschnitt »Implizite Abhängigkeiten« oben). Beachten
Sie auch, dass in diesem Fall Stdout (oder Stderr, siehe unten) ein AF_UNIX-Datenstrom-Socket und
keine PIPE oder FIFO, die erneut geöffnet werden kann, sein wird. Das bedeutet, dass bei der
Ausführung von Shell-Skripten die Konstruktion »echo "hello" > /dev/stderr« zum Schreiben von Text
nach Stderr nicht funktionieren wird. Um dies zu entschärfen, verwenden Sie stattdessen die
Konstruktion »echo "hello" >&2«, die größtenteils äquivalent ist und diesen Fallstrick vermeidet.
Der Vorgabewert dieser Einstellung ist der mit DefaultStandardOutput= in systemd-system.conf(5)
gesetzte Wert, der standardmäßig journal ist. Beachten Sie, dass dieser Parameter zum Hinzufügen
zusätzlicher Abhängigkeiten führen kann (siehe oben).
StandardError=
Steuert, womit Dateideskriptor 2 (STDERR) des ausgeführten Prozesses verbunden ist. Die verfügbaren
Optionen sind identisch zu denen von StandardOutput= mit einigen Ausnahmen: falls auf inherit
gesetzt, wird der für die Standardausgabe verwandte Dateideskriptor für die Standardfehlerausgabe
dupliziert, während fd:Name den vorgegebenen Dateideskriptornamen von »stderr« verwenden wird.
Der Vorgabewert dieser Einstellung ist der mit DefaultStandardError= in systemd-system.conf(5)
gesetzte Wert, der standardmäßig inherit ist. Beachten Sie, dass dieser Parameter zum Hinzufügen
zusätzlicher Abhängigkeiten führen kann (siehe oben).
StandardInputText=, StandardInputData=
Konfiguriert beliebige textuelle oder binäre Daten, die mittels Dateideskriptor 0 (STDIN) an den
ausgeführten Prozess übergeben werden sollen. Diese Einstellung hat keine Wirkung, außer
StandardInput= ist auf data gesetzt. Verwenden Sie diese Option, um Prozesseingabedaten direkt in die
Unit-Datei einzubetten.
StandardInputText= akzeptiert beliebige textuelle Daten. C-artige Maskierungen für besondere Zeichen
sowie die normalen »%«-Kennzeichner werden aufgelöst. Jedes Mal, wenn diese Einstellung benutzt wird,
wird der festgelegte Text an den Unit-bezogenen Datenpuffer, gefolgt von einem Zeilenumbruchzeichen,
angehängt (daher hängt jeder Einsatz eine neue Zeile an das Ende des Puffers an). Beachten Sie, dass
einleitende und abschließende Leerraumzeichen von mit dieser Option konfigurierten Zeilen entfernt
werden. Falls eine leere Zeile festgelegt wird, wird der Puffer bereinigt (daher sollte ein
zusätzliches »\n« an das Ende oder den Anfang einer Zeile eingefügt werden, um eine leere Zeile
einzufügen).
StandardInputData= akzeptiert beliebige, in Base64[4] kodierte binäre Daten. Es werden keine
Maskiersequenzen oder Kennzeichner aufgelöst. Sämtliche Leerraumzeichen in der kodierten Version
werden während der Dekodierung ignoriert.
Beachten Sie, dass StandardInputText= und StandardInputData= auf dem gleichen Datenpuffer arbeiten
und gemischt werden können, um sowohl binäre als auch textuelle Daten für den gleichen
Eingabedatenstrom zu konfigurieren. Die textuellen oder binären Daten werden genau in der Reihenfolge
zusammengefügt, in der sie in der Unit-Datei auftauchen. Wird einem eine leere Zeichenkette
zugewiesen, wird der Datenpuffer zurückgesetzt.
Bitte beachten Sie, dass lange Unit-Dateieinstellungen in mehrere Zeilen aufgeteilt werden können, um
die Lesbarkeit zu erhalten. Hierzu wird jeder Zeile (außer der letzten) ein Zeichen »\« vorangestellt
(siehe systemd.unit(5) für Details). Dies ist insbesondere für große Daten, die mit diesen Optionen
konfiguriert werden, nützlich. Beispiel:
…
StandardInput=data
StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl \
LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \
dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug \
enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \
SWNrZSEK
…
LogLevelMax=
Konfiguriert eine Filterung gemäß Protokollierstufe der durch diese Unit erstellten
Protokollnachrichten. Akzeptiert eine syslog-Protokollstufe, entweder emerg (niedrigste
Protokollierstufe, nur Nachrichten höchster Priorität), alert, crit, err, warning, notice, info oder
debug (höchste Protokollierstufe, auch Nachrichten niedrigster Priorität). Siehe syslog(3) für
Details. Standardmäßig wird keine Filterung angewandt (d.h. die maximale Protokollierstufe ist
standardmäßig debug). Verwenden Sie diese Option, um das Protokolliersystem zu konfigurieren, damit
es Protokollnachrichten eines bestimmten Dienstes oberhalb der festgelegten Stufe verwirft. Setzen
Sie beispielsweise LogLevelMax=info, um die Fehlersuchprotokollierung eines bestimmten, gesprächigen
Dienstes auszuschalten. Beachten Sie, dass die konfigurierte Stufe auf alle versandten
Protokollnachrichten aller zu diesem Dienst gehörenden Prozesse auf allen unterstützten
Protokollierungsprotokollen angewandt wird. Die Filterung erfolgt frühzeitig in der
Protokollierungspipeline, bevor jegliche Art weiterer Verarbeitung erfolgt. Desweiteren könnten
Nachrichten, die erfolgreich durch diesen Filter kommen, dennoch durch angewandte Filter in einer
späteren Stufe im Protokollierungsuntersystem verworfen werden. Beispielsweise könnte ein in
journald.conf(5) konfiguriertes MaxLevelStore= verbieten, Nachrichten von höheren Protokollierstufen
auf Platte zu speichen, selbst wenn das Unit-bezogene LogLevelMax= die Verarbeitung erlaubte.
LogExtraFields=
Konfiguriert zusätzliche Protokollmetadatenfelder, die in alle Protokolldatensätze aufgenommen
werden, die von Prozessen, die dieser Unit zugeordnet sind, erstellt werden. Diese Einstellung
akzeptiert eine oder mehrere Journal-Feldzuweisungen im Format »FELD=WERT«, getrennt durch
Leerraumzeichen. Siehe systemd.journal-fields(7) für Details zum Journal-Feldkonzept. Obwohl die
zugrundeliegende Journal-Implementierung binäre Feldnamen erlaubt, akzeptiert diese Einstellung nur
gültige UTF-8-Werte. Um Leerzeichen in einem Journal-Feldwert aufzunehmen, schließen Sie die
Zuweisung in doppelte Anführungszeichen (") ein. Die normalen Kennzeichner werden in allen
Zuweisungen expandiert (siehe unten). Beachten Sie, dass diese Einstellung nicht nur für das Anhängen
von zusätzlichen Metadaten an Protokolldatensätzen einer Unit nützlich ist. Da alle Felder und Werte
indiziert sind, kann dies auch für Unit-übergreifenden Protokolldatensatzabgleich verwandt werden.
Wird eine leere Zeichenkette zugewiesen, wird die Liste zurückgesetzt.
LogRateLimitIntervalSec=, LogRateLimitBurst=
Konfiguriert die Ratenbegrenzung, die auf von dieser Unit erstellte Nachrichten angewandt wird. Falls
in dem durch LogRateLimitIntervalSec= definierten Intervall mehr als in LogRateLimitBurst=
festgelegte Nachrichten durch den Dienst protokolliert werden, werden alle weiteren Nachrichten in
dem Intervall verworfen, bis das Intervall vorüber ist. Es wird eine Meldung über die verworfenen
Nachrichten erstellt. Die Zeitspezifikation für LogRateLimitIntervalSec= kann in einer der folgenden
Einheiten erfolgen: »s«, »min«, »h«, »ms«, »us« (siehe systemd.time(7) für Details). Die
Voreinstellungen erfolgen durch die in journald.conf(5) konfigurierten RateLimitIntervalSec= und
RateLimitBurst=.
SyslogIdentifier=
Setzt den Prozessnamen (»syslog-Markierung«), der allen an das Protokollierungssystem oder den
Kernelpuffer gesandten langen Zeilen vorangestellt werden soll. Falls nicht gesetzt, ist die Vorgabe
der Prozessname des ausgeführten Prozesses. Diese Option ist nur nützlich, wenn StandardOutput= oder
StandardError= auf journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit
+console). Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden,
angewandt.
SyslogFacility=
Setzt den syslog-Einrichtungskennzeichner, der beim Protokollieren verwandt werden soll. Entweder
kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, authpriv, ftp, local0, local1, local2,
local3, local4, local5, local6 oder local7. Siehe syslog(3) für Details. Diese Option ist nur
nützlich, wenn StandardOutput= oder StandardError= auf journal oder kmsg gesetzt ist (oder die
gleichen Einstellungen in Kombination mit +console). Sie wird nur auf Protokollnachrichten, die nach
Stdout oder Stderr geschrieben werden, angewandt. Standardmäßig daemon.
SyslogLevel=
Die Vorgabe-syslog-Protokollierstufe, die beim Protokollieren zum Protokollierungssystem oder
Kernelprotokollpuffer verwandt werden soll. Entweder emerg, alert, crit, err, warning, notice, info
oder debug. Siehe syslog(3) für Details. Diese Option ist nur nützlich, wenn StandardOutput= oder
StandardError= auf journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit
+console). Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden,
angewandt. Beachten Sie, dass individuellen Zeilen, die von ausgeführten Prozessen ausgegeben werden,
eine andere Protokollierungsstufe vorangestellt werden kann, die dazu verwandt werden kann, die hier
festgelegte Vorgabeprotokollstufe außer Kraft zu setzen. Die Auswertung dieser vorangestellten Werte
kann mit SyslogLevelPrefix= deaktiviert werden, siehe unten. Für Details siehe sd-daemon(3).
Standardmäßig info.
SyslogLevelPrefix=
Akzeptiert ein logisches Argument. Falls wahr und StandardOutput= oder StandardError= auf journal
oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit +console), wird
Protokollzeilen, die durch die ausgeführten Prozesse geschrieben werden, denen eine
Protokollierungsstufe vorangestellt ist, verarbeitet, wobei die vorangestellte Protokollierungsstufe
entfernt wird. Falls auf falsch gesetzt, wird die Auswertung dieser vorangestellten Werte deaktiviert
und die protokollierten Zeilen unverändert weitergegeben. Dies gilt nur für Protokollnachrichten, die
nach Stdout oder Stderr geschrieben werden. Für Details bezüglich des Voranstellens siehe
sd-daemon(3). Standardmäßig wahr.
TTYPath=
Setzt den zu verwendenden Terminalgeräteknoten, falls die Standardeingabe, -ausgabe oder
-fehlerausgabe mit einem TTY verbunden ist (siehe oben). Standardmäßig /dev/console.
TTYReset=
Setzt das mit TTYPath= festgelegte Terminalgerät vor und nach der Ausführung zurück. Standardmäßig
»no«.
TTYVHangup=
Trennt alle Clients, die das mit TTYPath= festgelegte Terminalgerät vor und nach der Ausführung
geöffnet haben. Standardmäßig »no«.
TTYVTDisallocate=
If the terminal device specified with TTYPath= is a virtual console terminal, try to deallocate the
TTY before and after execution. This ensures that the screen and scrollback buffer is cleared.
Defaults to "no".
SYSTEM V-KOMPATIBILITÄT
UtmpIdentifier=
Akzeptiert eine Kennzeichnungszeichenkette aus vier Zeichen für einen utmp(5)- und Wtmp-Eintrag für
diesen Dienst. Dies sollte nur für Dienste wie getty-Implementierungen (wie agetty(8)) gesetzt
werden, bei denen Utmp/Wtmp-Einträge erstellt und vor und nach der Ausführung bereinigt werden müssen
oder für Dienste, die so ausgeführt werden sollen, als ob sie durch einen getty-Prozess ausgeführt
würden (siehe unten). Falls die Konfigurationszeichenkette länger als vier Zeichen ist, wird sie
gekürzt und die vier Zeichen am Ende werden verwandt. Diese Einstellung interpretiert %I-artige
Zeichenkettenersetzungen. Diese Einstellung ist standardmäßig nicht gesetzt, d.h. dass für diesen
Dienst keine Utmp-/Wtmp-Einträge erstellt oder bereinigt werden.
UtmpMode=
Akzeptiert entweder »init«, »login« oder »user«. Falls UtmpIdentifier= gesetzt ist, steuert dies die
Art der für diesen Dienst erstellten utmp(5)/wtmp-Einträge. Diese Einstellung ist wirkungslos, außer
UtmpIdentifier= ist auch gesetzt. Falls »init« gesetzt ist, wird nur ein INIT_PROCESS-Eintrag
erstellt und der aufgerufene Prozess muss eine getty-kompatible Utmp/Wtmp-Logik implementieren. Falls
»login« gesetzt ist, wird zuerst ein INIT_PROCESS-Eintrag, gefolgt von einem LOGIN_PROCESS-Eintrag
erstellt. In diesem Fall muss der aufgerufene Prozess eine login(1)-kompatible Utmp/Wtmp-Logik
implementieren. Falls »user« festgelegt ist, wird zuerst ein INIT_PROCESS-Eintrag, dann ein
LOGIN_PROCESS-Eintrag und schließlich ein USER_PROCESS-Eintrag erstellt. In diesem Fall kann der
Prozess jeder Prozess sein, der zum Betrieb als Sitzungsleiter geeignet ist. Standardmäßig »init«.
UMGEBUNGSVARIABLEN IN ERZEUGTEN PROZESSEN
Durch den Diensteverwalter gestartete Prozesse werden mit einem Umgebungsvariablenblock gestartet, der
aus verschiedenen Quellen zusammengesetzt ist. Prozesse, die durch den Systemdiensteverwalter gestartet
werden, erben im Allgemeinen die für den Diensteverwalter selbst gesetzten Umgebungsvariablen nicht (dies
kann durch PassEnvironment= geändert werden), aber Prozesse, die durch Benutzerdiensteverwalterinstanzen
gestartet werden, erben im Allgemein alle für den Diensteverwalter selbst gesetzten Umgebungsvariablen.
Für jeden aufgerufenen Prozess wird die Liste der gesetzten Umgebungsvariablen aus den folgenden Quellen
zusammengestellt:
• Variablen, die global für den Diensteverwalter mittels der Einstellung DefaultEnvironment= in
systemd-system.conf(5), der Kernelbefehlszeilenoption systemd.setenv= (siehe systemd(1)) oder mittels
systemctl set-environment (siehe systemctl(1)) konfiguriert sind.
• Durch den Diensteverwalter selbst definierte Variablen (siehe nachfolgende Liste)
• Variablen, die durch den Umgebungsvariablenblock des Diensteverwalters selbst gesetzt sind (abhängig
von PassEnvironment= für den Systemdiensteverwalter)
• Mittels Environment= in der Unit-Datei gesetzte Variablen
• Aus mit EnvironmentFile= in der Unit-Datei festgelegten Dateien gelesene Variablen
• Falls PAMName= wirksam ist, siehe pam_env(8), durch alle PAM-Module gesetzte Variablen
Falls die gleichen Umgebungsvariablen aus mehreren dieser Quellen gesetzt werden, gewinnt die letzte
Quelle, wobei die Reihenfolge der obigen Liste zählt. Beachten Sie, dass als abschließender Schritt alle
in UnsetEnvironment= aufgeführten Variablen wieder von der zusammengestellten Variablenliste entfernt
werden, direkt bevor sie an den ausgeführten Prozess übergeben wird.
Die folgenden ausgewählten Umgebungsvariablen werden für jeden durch den Diensteverwalter aufgerufenen
Prozess gesetzt oder ausgebreitet:
$PATH
Doppelpunkt-getrennte Liste von Verzeichnissen, die beim Starten von Programmen verwandt werden.
systemd verwendet eine festgelegten Wert von »/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin« im
Systemverwalter. Wird dies auf Systemen mit »nicht zusammengeführtem /usr« (/bin ist kein Symlink auf
/usr/bin) kompiliert, wird »:/sbin:/bin« angehängt. Im Falle des Benutzerverwalters, wird jedes /bin-
und /sbin-Paar getauscht, so dass Programme aus /usr/bin höhere Priorität als solche aus /usr/sbin
usw. haben. Es wird empfohlen, sich darauf nicht in irgendeiner Weise zu verlassen, und nur ein
Programm mit einem vorgegebenen Namen in $PATH zu haben.
$LANG
Locale. Kann in locale.conf(5) oder auf der Kernelbefehlszeile gesetzt werden (siehe systemd(1) und
kernel-command-line(7)).
$USER, $LOGNAME, $HOME, $SHELL
Benutzername (zweifach), Home-Verzeichnis und die Anmelde-Shell. Die Variablen sind für die Units,
die User= gesetzt haben, gesetzt, dazu gehören Benutzer-systemd-Instanzen. Siehe passwd(5).
$INVOCATION_ID
Enthält eine zufällige, eindeutige, 128-Bit-Kennzeichnung, die jeden Laufzeitzyklus der Unit
identifiziert. Sie ist als hexadezimale Zeichenkette mit 32 Zeichen formatiert. Jedes Mal, wenn die
Unit sich vom inaktiven Zustand in einen aktivierenden oder aktiven Zustand ändert, wird eine neue
Kennung zugewiesen. Sie kann zur Kennzeichnung dieses bestimmten Laufzeitzyklus verwandt werden,
insbesondere in gespeicherten Daten wie dem Journal. Die gleiche Kennung wird an alle als Teil der
Unit ausgeführten Prozesse übergeben.
$XDG_RUNTIME_DIR
Das Verzeichnis, das für Laufzeitobjekte (wie IPC-Objekte) und flüchtige Zustände verwandt werden
soll. Wird für alle von der Benutzer-systemd-Instanz ausgeführten Prozesse sowie von allen
Systemdiensten, die PAMName= mit einem PAM-Stack, der pam_systemd enthält, verwandt wird, gesetzt.
Siehe unten und pam_systemd(8) für weitere Informationen.
$MAINPID
Die PID des Hauptprozesses der Unit, falls bekannt. Dies wird nur für durch ExecReload= und Ähnliches
aufgerufene Steuerprozesse gesetzt.
$MANAGERPID
Die PID der Benutzer-systemd-Instanz, gesetzt für davon erzeugte Prozesse.
$LISTEN_FDS, $LISTEN_PID, $LISTEN_FDNAMES
Informationen über Dateideskriptoren, die an einen Dienst für Socket-Aktivierung weitergegeben
wurden. Siehe sd_listen_fds(3).
$NOTIFY_SOCKET
Das Socket, mit dem sd_notify() kommuniziert. Siehe sd_notify(3).
$WATCHDOG_PID, $WATCHDOG_USEC
Informationen über Watchdog-Aufrechterhaltungsbenachrichtigungen. Siehe sd_watchdog_enabled(3).
$TERM
Terminaltyp, nur für mit einem Terminal verbundene Units gesetzt (StandardInput=tty,
StandardOutput=tty oder StandardError=tty). Siehe termcap(5).
$JOURNAL_STREAM
Falls die Standardausgabe oder Standardfehlerausgabe des ausgeführten Prozesses mit dem Journal
verbunden ist (beispielsweise durch Setzen von StandardError=journal), enthält $JOURNAL_STREAM das
Gerät und die Inode-Nummer des verbindenden Dateideskriptors, dezimal formatiert, getrennt durch
einen Doppelpunkt (»:«). Dies erlaubt es aufgerufenen Prozessen, sicher zu überprüfen, ob ihre
Standardausgabe oder Standardfehlerausgabe mit dem Journal verbunden sind. Das Gerät und die
Inode-Nummer des Dateideskriptors sollte mit den in der Umgebungsvariable gesetzten Werten verglichen
werden, um zu bestimmen, ob die Prozessausgabe immer noch mit dem Journal verbunden ist. Beachten
Sie, dass es im Allgemeinen nicht ausreicht, zu prüfen, ob $JOURNAL_STREAM überhaupt gesetzt ist, da
Dienste externe Prozesse aufrufen könnten, die ihre Standardausgabe oder Fehlerausgabe ersetzen
könnten, ohne dabei die Umgebungsvariable zurückzusetzen.
Falls sowohl die Standardausgabe als auch der Standardfehler des ausgeführten Prozesses mit dem
Journal über ein Datenstrom-Socket verbunden sind, wird diese Umgebungsvariable Informationen über
den Standardfehlerdatenstrom enthalten, da dies normalerweise das bevorzugte Ziel für Protokolldaten
ist. (Beachten Sie, dass typischerweise der gleiche Datenstrom sowohl für die Standardausgabe als
auch den Standardfehler verwandt wird und daher die Umgebungsvariable sehr wahrscheinlich Geräte- und
Inode-Informationen enthalten wird, die auf beide Datenstromdateideskriptoren passt.)
Diese Umgebungsvariable ist hauptsächlich nützlich, um Diensten zu erlauben, ihr verwandtes
Protokollierungsprotokoll optional (mittels sd_journal_print(3) und anderer Funktionen) auf das
native Journal-Protokoll anzuheben, falls ihre Standardausgabe oder Standardfehlerausgabe sowieso mit
dem Journal verbunden ist. Damit wird die Lieferung von strukturierten Metadaten zusammen mit den
protokollierten Nachrichten ermöglicht.
$SERVICE_RESULT
Diese Variable, die nur für den Dienste-Unit-Typ definiert ist, wird an alle ExecStop=- und
ExecStopPost=-Prozesse weitergegeben und kodiert das »Ergebnis« des Prozesses. Derzeit sind die
folgenden Werte definiert:
Tabelle 4. Definierte $SERVICE_RESULT-Werte
┌───────────────────┬───────────────────────────────────────┐
│ Wert │ Bedeutung │
├───────────────────┼───────────────────────────────────────┤
│ "Erfolg" │ Der Dienst lief erfolgreich und │
│ │ beendete sich ordnungsgemäß. │
├───────────────────┼───────────────────────────────────────┤
│ "protocol" │ Das Protokoll wurde verletzt: der │
│ │ Dienst hat nicht die von seiner │
│ │ Unit-Konfiguration verlangten │
│ │ Schritte absolviert (insbesondere was │
│ │ in der Einstellung Type= konfiguriert │
│ │ wurde). │
├───────────────────┼───────────────────────────────────────┤
│ "timeout" │ Einer der Schritte hat die Zeit │
│ │ überschritten. │
├───────────────────┼───────────────────────────────────────┤
│ "exit-code" │ Diensteprozess hat sich mit einen von │
│ │ Null verschiedenen Exit-Code beendet; │
│ │ siehe $EXIT_CODE unten für den │
│ │ tatsächlich zurückgelieferten │
│ │ Exit-Code. │
├───────────────────┼───────────────────────────────────────┤
│ "signal" │ Ein Diensteprozess wurde durch ein │
│ │ Signal regelwidrig beendet; ohne │
│ │ einen Speicherauszug. Siehe │
│ │ $EXIT_CODE unten für das tatsächliche │
│ │ Signal, das die Beendigung auslöste. │
├───────────────────┼───────────────────────────────────────┤
│ "core-dump" │ Ein Diensteprozess wurde durch ein │
│ │ Signal regelwidrig beendet und hat │
│ │ einen Speicherauszug ausgegeben. │
│ │ Siehe $EXIT_CODE unten für das │
│ │ Signal, das die Beendigung auslöste. │
├───────────────────┼───────────────────────────────────────┤
│ "watchdog" │ Der Totmannschalter des Watchdogs war │
│ │ für diesen Dienst aktiviert, aber die │
│ │ Frist wurde verpasst. │
├───────────────────┼───────────────────────────────────────┤
│ "start-limit-hit" │ Für die Unit war eine Startbegrenzung │
│ │ definiert und wurde erreicht, wodurch │
│ │ der Start der Unit fehlschlug. Siehe │
│ │ StartLimitIntervalSec= und │
│ │ StartLimitBurst= von systemd.unit(5) │
│ │ für Details. │
├───────────────────┼───────────────────────────────────────┤
│ "resources" │ Eine Auffangbedingung, falls eine │
│ │ Systemaktion fehlschlug. │
└───────────────────┴───────────────────────────────────────┘
Diese Umgebungsvariable ist nützlich, um den Fehlschlag oder die erfolgreiche Beendigung eines
Dienstes zu überwachen. Obwohl diese Variable sowohl in ExecStop= als auch ExecStopPost= verfügbar
ist, ist es normalerweise eine bessere Wahl, die Überwachungswerkzeuge in Letzterer zu platzieren, da
Erstere nur für Dienste aufgerufen wird, die ihren Start korrekt verwaltet haben und Letztere sowohl
Dienste abdeckt, die während ihres Startens fehlschlugen als auch solche, die während ihrer Laufzeit
fehlschlugen.
$EXIT_CODE, $EXIT_STATUS
Diese Umgebungsvariablen, die nur für den Dienste-Unit-Typ definiert sind, werden an alle Prozesse
aus ExecStop= und ExecStopPost= übergeben und enthalten Exit-Status/Code-Informationen über den
Hauptprozess des Dienstes. Für die genaue Definition des Exit-Codes und -Status, siehe wait(2).
$EXIT_CODE ist entweder »exited«, »killed« oder »dumped«. $EXIT_STATUS enthält den als Zeichenkette
formatierten numerischen Exit-Code, falls $EXIT_CODE »exited« enthält und andernfalls den
Signalnamen. Beachten Sie, dass diese Umgebungsvariablen nur gesetzt sind, falls es dem
Diensteverwalter gelang, den Hauptprozess des Dienstes zu starten und zu identifizieren.
Tabelle 5. Zusammenfassung der möglichen Variablenwerte für Diensteergebnisse
┌─────────────────────────┬────────────────────────┬───────────────────────────────────┐
│ $SERVICE_RESULT │ $EXIT_CODE │ $EXIT_STATUS │
├─────────────────────────┼────────────────────────┼───────────────────────────────────┤
│ "Erfolg" │ "exited" │ "0" │
├─────────────────────────┼────────────────────────┼───────────────────────────────────┤
│ "protocol" │ not set │ not set │
│ ├────────────────────────┼───────────────────────────────────┤
│ │ "exited" │ "0" │
├─────────────────────────┼────────────────────────┼───────────────────────────────────┤
│ "timeout" │ "killed" │ »TERM«, »KILL« │
│ ├────────────────────────┼───────────────────────────────────┤
│ │ "exited" │ »0«, »1«, »2«, »3«, … »255« │
├─────────────────────────┼────────────────────────┼───────────────────────────────────┤
│ "exit-code" │ "exited" │ »1«, »2«, »3«, …, »255« │
├─────────────────────────┼────────────────────────┼───────────────────────────────────┤
│ "signal" │ "killed" │ »HUP«, »INT«, »KILL«, … │
├─────────────────────────┼────────────────────────┼───────────────────────────────────┤
│ "core-dump" │ "dumped" │ »ABRT«, »SEGV«, »QUIT«, … │
├─────────────────────────┼────────────────────────┼───────────────────────────────────┤
│ "watchdog" │ "dumped" │ "ABRT" │
│ ├────────────────────────┼───────────────────────────────────┤
│ │ "killed" │ »TERM«, »KILL« │
│ ├────────────────────────┼───────────────────────────────────┤
│ │ "exited" │ »0«, »1«, »2«, »3«, … »255« │
├─────────────────────────┼────────────────────────┼───────────────────────────────────┤
│ "start-limit-hit" │ not set │ not set │
├─────────────────────────┼────────────────────────┼───────────────────────────────────┤
│ "resources" │ jeder der obigen │ jeder der obigen │
├─────────────────────────┴────────────────────────┴───────────────────────────────────┤
│ Beachten Sie: der Prozess kann auch durch ein Signal beendet werden, das nicht von │
│ Systemd gesandt wurde. Insbesondere kann der Prozess sich selbst in einem Handler │
│ ein beliebiges Signal für jedes der nicht maskierbaren Signale senden. │
│ Nichtsdestotrotz wurden in den Spalten »timeout« und »watchdog« nur die Signale │
│ aufgenommen, die Systemd sendet. Desweiteren können mittels SuccessExitStatus= │
│ zusätzliche Exit-Status erklärt werden, um die ordnungsgemäße Beendigung anzuzeigen, │
│ was in der Tabelle nicht wiedergegeben wird. │
└──────────────────────────────────────────────────────────────────────────────────────┘
$PIDFILE
Der Pfad zu der konfigurierten PID-Datei, falls der Prozess im Auftrag des Dienstes, der die
Einstellung PIDFile= verwendet, einen Fork durchgeführt hat, siehe systemd.service(5) für Details.
Dienste-Code kann diese Umgebungsvariable verwenden, um automatisch eine PID-Datei am durch die
Unit-Datei konfigurierten Ort zu erstellen. Dieses Feld ist auf einen absoluten Pfad in dem
Dateisystem gesetzt.
Für Systemdienste können zusätzliche, durch Systemd definierte Umgebungsvariablen für Dienste gesetzt
werden, wenn PAMName= aktiviert und pam_systemd Teil des ausgewählten PAM-Stacks ist. Dies sind
insbesondere $XDG_SEAT und $XDG_VTNR, siehe pam_systemd(8) für Details.
PROZESS-EXIT-CODES
Beim Aufruf eines Unit-Prozesses könnte der Diensteverwalter möglicherweise nicht in der Lage sein, die
mit den oben dargestellten Einstellungen konfigurierten Ausführungsparameter zu setzen. In diesem Fall
wird sich der bereits erstellte Diensteprozess mit einem von Null verschiedenen Exit-Code beenden, bevor
die konfigurierte Befehlszeile ausgeführt wird. (Oder, mit anderen Worten, der Kindprozess hat sich mit
diesen Fehler-Codes beendet, nachdem er mit dem Systemaufruf fork(2) erstellt wurde, aber bevor der
zugehörige Systemaufruf execve(2) erfolgte.) Insbesondere werden die durch die C-Bibliothek, die
LSB-Spezifikation und durch den Systemd-Diensteverwalter selbst definierten Exit-Codes verwandt.
Die folgenden grundlegenden Dienste-Exit-Codes sind durch die C-Bibliothek definiert.
Tabelle 6. Grundlegende Exit-Codes der C-Bibliothek
┌───────────┬───────────────────┬─────────────────────────────┐
│ Exit-Code │ Symbolischer Name │ Beschreibung │
├───────────┼───────────────────┼─────────────────────────────┤
│ 0 │ EXIT_SUCCESS │ Generischer Erfolgs-Code. │
├───────────┼───────────────────┼─────────────────────────────┤
│ 1 │ EXIT_FAILURE │ Generischer Fehlschlag oder │
│ │ │ unspezifizierter Fehler. │
└───────────┴───────────────────┴─────────────────────────────┘
Die folgenden Dienste-Exit-Codes sind durch die LSB-Spezifikation[5] festgelegt.
Tabelle 7. LSB-Dienste-Exit-Codes
┌───────────┬──────────────────────┬──────────────────────────────┐
│ Exit-Code │ Symbolischer Name │ Beschreibung │
├───────────┼──────────────────────┼──────────────────────────────┤
│ 2 │ EXIT_INVALIDARGUMENT │ Ungültige oder überzählige │
│ │ │ Argumente. │
├───────────┼──────────────────────┼──────────────────────────────┤
│ 3 │ EXIT_NOTIMPLEMENTED │ Nicht implementierte │
│ │ │ Funktionalität. │
├───────────┼──────────────────────┼──────────────────────────────┤
│ 4 │ EXIT_NOPERMISSION │ Der Benutzer hat nicht genug │
│ │ │ Privilegien. │
├───────────┼──────────────────────┼──────────────────────────────┤
│ 5 │ EXIT_NOTINSTALLED │ Das Programm ist nicht │
│ │ │ installiert. │
├───────────┼──────────────────────┼──────────────────────────────┤
│ 6 │ EXIT_NOTCONFIGURED │ Das Programm ist nicht │
│ │ │ konfiguriert. │
├───────────┼──────────────────────┼──────────────────────────────┤
│ 7 │ EXIT_NOTRUNNING │ Das Programm läuft nicht. │
└───────────┴──────────────────────┴──────────────────────────────┘
Die LSB-Spezifikation schlägt vor, dass Fehler-Code 200 und höher für Implementierungen reserviert ist.
Einige von ihnen werden vom Diensteverwalter benutzt, um Probleme beim Aufrufen von Prozessen anzuzeigen.
Tabelle 8. Systemd-spezifische Exit-Codes
┌───────────┬──────────────────────────────┬─────────────────────────────────────────────┐
│ Exit-Code │ Symbolischer Name │ Beschreibung │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 200 │ EXIT_CHDIR │ Änderung des angeforderten │
│ │ │ Arbeitsverzeichnisses schlug │
│ │ │ fehl. Siehe │
│ │ │ WorkingDirectory= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 201 │ EXIT_NICE │ Scheduling-Priorität │
│ │ │ (Nice-Stufe) konnte nicht │
│ │ │ gesetzt werden. Siehe Nice= │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 202 │ EXIT_FDS │ Ungewünschter │
│ │ │ Dateideskriptor konnte nicht │
│ │ │ geschlossen werden oder │
│ │ │ übergebene Dateideskriptoren │
│ │ │ konnten nicht angepasst │
│ │ │ werden. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 203 │ EXIT_EXEC │ Die tatsächliche Ausführung │
│ │ │ des Prozesses schlug fehl │
│ │ │ (genauer, der Systemaufruf │
│ │ │ execve(2)). │
│ │ │ Höchstwahrscheinlich wird │
│ │ │ dies durch ein fehlendes │
│ │ │ oder nicht zugreifbares │
│ │ │ Programm hervorgerufen. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 204 │ EXIT_MEMORY │ Aufgrund von │
│ │ │ Speicherknappheit konnte │
│ │ │ eine Aktion nicht │
│ │ │ durchgeführt werden. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 205 │ EXIT_LIMITS │ Ressourcenbegrenzungen │
│ │ │ konnten nicht angepasst │
│ │ │ werden. Siehe LimitCPU= und │
│ │ │ verwandte Einstellungen │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 206 │ EXIT_OOM_ADJUST │ OOM-Einstellungen konnten │
│ │ │ nicht angepasst werden. │
│ │ │ Siehe OOMScoreAdjust= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 207 │ EXIT_SIGNAL_MASK │ Prozesssignalmaske konnte │
│ │ │ nicht gesetzt werden. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 208 │ EXIT_STDIN │ Standardeingabe konnte nicht │
│ │ │ gesetzt werden. Siehe │
│ │ │ StandardInput= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 209 │ EXIT_STDOUT │ Standardausgabe konnte nicht │
│ │ │ gesetzt werden. Siehe │
│ │ │ StandardOutput= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 210 │ EXIT_CHROOT │ Wurzelverzeichnis konnte │
│ │ │ nicht geändert werden │
│ │ │ (chroot(2)). Siehe │
│ │ │ RootDirectory=/RootImage= │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 211 │ EXIT_IOPRIO │ E/A-Scheduling-Priorität │
│ │ │ konnte nicht gesetzt werden. │
│ │ │ Siehe │
│ │ │ IOSchedulingClass=/IOSchedulingPriority= │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 212 │ EXIT_TIMERSLACK │ Der Zeitgeberspielraum konnte nicht │
│ │ │ eingerichtet werden. Siehe │
│ │ │ TimerSlackNSec= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 213 │ EXIT_SECUREBITS │ Prozess-Sicherheits-Bits konnten nicht │
│ │ │ gesetzt werden. Siehe SecureBits= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 214 │ EXIT_SETSCHEDULER │ CPU-Scheduling konnte nicht eingerichtet │
│ │ │ werden. Siehe │
│ │ │ CPUSchedulingPolicy=/CPUSchedulingPriority= │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 215 │ EXIT_CPUAFFINITY │ CPU-Affinität konnte nicht eingerichtet │
│ │ │ werden. Siehe CPUAffinity= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 216 │ EXIT_GROUP │ Gruppen-Zugangsdaten konnten nicht bestimmt │
│ │ │ oder geändert werden. Siehe │
│ │ │ Group=/SupplementaryGroups= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 217 │ EXIT_USER │ Benutzer-Zugangsdaten konnten nicht │
│ │ │ bestimmt oder geändert werden oder │
│ │ │ Benutzernamensräume eingerichtet werden. │
│ │ │ Siehe User=/PrivateUsers= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 218 │ EXIT_CAPABILITIES │ Capabilities konnten nicht abgegeben oder │
│ │ │ Umgebungs-Capabilities angewandt werden. │
│ │ │ Siehe │
│ │ │ CapabilityBoundingSet=/AmbientCapabilities= │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 219 │ EXIT_CGROUP │ Einrichten der Dienste-Control-Gruppe │
│ │ │ schlug fehl. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 220 │ EXIT_SETSID │ Erstellung einer neuen Prozesssitzung │
│ │ │ schlug fehl. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 221 │ EXIT_CONFIRM │ Ausführung wurde vom Benutzer abgebrochen. │
│ │ │ Siehe die Kernelbefehlszeileneinstellung │
│ │ │ systemd.confirm_spawn= in │
│ │ │ kernel-command-line(7) für Details. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 222 │ EXIT_STDERR │ Standardfehlerausgabe konnte nicht │
│ │ │ eingerichtet werden. Siehe StandardError= │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 224 │ EXIT_PAM │ PAM-Sitzung konnte nicht eingerichtet │
│ │ │ werden. Siehe PAMName= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 225 │ EXIT_NETWORK │ Netzwerknamensräume konnten nicht │
│ │ │ eingericht werden. Siehe PrivateNetwork= │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 226 │ EXIT_NAMESPACE │ Einhängenamensräume konnten nicht │
│ │ │ eingerichtet werden. Siehe ReadOnlyPaths= │
│ │ │ und verwandte Einstellungen oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 227 │ EXIT_NO_NEW_PRIVILEGES │ Neue Privilegien konnten nicht deaktiviert │
│ │ │ werden. Siehe NoNewPrivileges=yes oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 228 │ EXIT_SECCOMP │ Systemaufruffilter konnten nicht angewandt │
│ │ │ werden. Siehe SystemCallFilter= und │
│ │ │ verwandte Einstellungen oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 229 │ EXIT_SELINUX_CONTEXT │ SELinux-Kontext konnte nicht bestimmt oder │
│ │ │ geändert werden Siehe SELinuxContext= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 230 │ EXIT_PERSONALITY │ Ausführungsdomäne (Personalität) konnte │
│ │ │ nicht eingerichtet werden. Siehe │
│ │ │ Personality= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 231 │ EXIT_APPARMOR_PROFILE │ AppArmor konnte nicht vorbereitet werden. │
│ │ │ SIehe AppArmorProfile= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 232 │ EXIT_ADDRESS_FAMILIES │ Adressfamilien konnten nicht beschränkt │
│ │ │ werden. Siehe RestrictAddressFamilies= │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 233 │ EXIT_RUNTIME_DIRECTORY │ Laufzeitverzeichnis konnte nicht │
│ │ │ eingerichtet werden. Siehe │
│ │ │ RuntimeDirectory= und verwandte │
│ │ │ Einstellungen oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 235 │ EXIT_CHOWN │ Socket-Eigentümerschaft konnte nicht │
│ │ │ angepasst werden. Wird nur für Socket-Units │
│ │ │ verwandt. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 236 │ EXIT_SMACK_PROCESS_LABEL │ SMACK-Sicherheits-Label konnte nicht │
│ │ │ gesetzt werden. Siehe SmackProcessLabel= │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 237 │ EXIT_KEYRING │ Kernel-Schlüsselbund konnte nicht │
│ │ │ eingerichtet werden. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 238 │ EXIT_STATE_DIRECTORY │ Zustandsverzeichnis der Unit konnte nicht │
│ │ │ eingerichtet werden. Siehe StateDirectory= │
│ │ │ oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 239 │ EXIT_CACHE_DIRECTORY │ Zwischenspeicherverzeichnis der Unit konnte │
│ │ │ nicht eingerichtet werden. Siehe │
│ │ │ CacheDirectory= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 240 │ EXIT_LOGS_DIRECTORY │ Protokollierverzeichnis der Unit konnte │
│ │ │ nicht eingerichtet werden. Siehe │
│ │ │ LogsDirectory= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 241 │ EXIT_CONFIGURATION_DIRECTORY │ Konfigurationsverzeichnis der Unit konnte │
│ │ │ nicht eingerichtet werden. Siehe │
│ │ │ ConfigurationDirectory= oben. │
├───────────┼──────────────────────────────┼─────────────────────────────────────────────┤
│ 242 │ EXIT_NUMA_POLICY │ NUMA-Richtlinie der Unit konnte nicht │
│ │ │ eingerichtet werden. Siehe NUMAPolicy= und │
│ │ │ NUMAMask= oben. │
└───────────┴──────────────────────────────┴─────────────────────────────────────────────┘
Schließlich definieren die BSD-Betriebssysteme eine Reihe von Exit-Codes, die typischerweise auch auf
Linux-Systemen definiert sind:
Tabelle 9. BSD-Exit-Codes
┌───────────┬───────────────────┬───────────────────────────────┐
│ Exit-Code │ Symbolischer Name │ Beschreibung │
├───────────┼───────────────────┼───────────────────────────────┤
│ 64 │ EX_USAGE │ Befehlszeilenbenutzungsfehler │
├───────────┼───────────────────┼───────────────────────────────┤
│ 65 │ EX_DATAERR │ Datenformatfehler │
├───────────┼───────────────────┼───────────────────────────────┤
│ 66 │ EX_NOINPUT │ Eingabe kann nicht geöffnet │
│ │ │ werden │
├───────────┼───────────────────┼───────────────────────────────┤
│ 67 │ EX_NOUSER │ Empfängerin unbekannt │
├───────────┼───────────────────┼───────────────────────────────┤
│ 68 │ EX_NOHOST │ Rechnername unbekannt │
├───────────┼───────────────────┼───────────────────────────────┤
│ 69 │ EX_UNAVAILABLE │ Dienst nicht verfügbar │
├───────────┼───────────────────┼───────────────────────────────┤
│ 70 │ EX_SOFTWARE │ interner Softwarefehler │
├───────────┼───────────────────┼───────────────────────────────┤
│ 71 │ EX_OSERR │ Systemfehler (z.B. Fork kann │
│ │ │ nicht ausgeführt werden) │
├───────────┼───────────────────┼───────────────────────────────┤
│ 72 │ EX_OSFILE │ kritische Betriebssystemdatei │
│ │ │ fehlt │
├───────────┼───────────────────┼───────────────────────────────┤
│ 73 │ EX_CANTCREAT │ (Benutzer)-Ausgabedatei kann │
│ │ │ nicht erstellt werden │
├───────────┼───────────────────┼───────────────────────────────┤
│ 74 │ EX_IOERR │ Eingabe/Ausgabe-Fehler │
├───────────┼───────────────────┼───────────────────────────────┤
│ 75 │ EX_TEMPFAIL │ Temporärer Fehlschlag, │
│ │ │ Benutzer sollte es noch │
│ │ │ einmal versuchen │
├───────────┼───────────────────┼───────────────────────────────┤
│ 76 │ EX_PROTOCOL │ Ferner Fehler im Protokoll │
├───────────┼───────────────────┼───────────────────────────────┤
│ 77 │ EX_NOPERM │ Erlaubnis verweigert │
├───────────┼───────────────────┼───────────────────────────────┤
│ 78 │ EX_CONFIG │ Konfigurationsfehler │
└───────────┴───────────────────┴───────────────────────────────┘
SIEHE AUCH
systemd(1), systemctl(1), systemd-analyze(1), journalctl(1), systemd-system.conf(5), systemd.unit(5),
systemd.service(5), systemd.socket(5), systemd.swap(5), systemd.mount(5), systemd.kill(5),
systemd.resource-control(5), systemd.time(7), systemd.directives(7), tmpfiles.d(5), exec(3)
ANMERKUNGEN
1. Spezifikation für auffindbare Partitionen
https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
2. Schalter »Keine neuen Privilegien«
https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html
3. proc.txt
https://www.kernel.org/doc/Documentation/filesystems/proc.txt
4. Base64
https://tools.ietf.org/html/rfc2045#section-6.8
5. LSB-Spezifikation
https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
Ü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
<debian-l10n-german@lists.debian.org>.
systemd 243 SYSTEMD.EXEC(5)