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 │ Unterhalb vom Pfad │ Umgebungsvariablenmenge │
│ │ von System-Units │ von 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>.