.\" -*- coding: UTF-8 -*-
'\" t
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH SYSTEMD\&.EXEC 5 "" "systemd 241" systemd.exec
.ie  \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH BEZEICHNUNG
systemd.exec \- Konfiguration der Ausführungsumgebung
.SH ÜBERSICHT
.PP
\fIDienst\fP\&.service, \fISocket\fP\&.socket, \fIEinhängung\fP\&.mount,
\fISwap\fP\&.swap
.SH BESCHREIBUNG
.PP
Unit\-Konfigurationsdateien für Dienste, Sockets, Einhängepunkte und
Auslagerungsgeräte nutzen eine Teilmenge der Konfigurationsoptionen, die die
Ausführungsumgebung von gestarteten Prozessen definieren\&.
.PP
Diese Handbuchseite listet die Konfigurationsoptionen auf, die von diesen
vier Unit\-Typen gemeinsam benutzt werden\&. Siehe \fBsystemd.unit\fP(5) für die
Konfiguration der von allen Unit\-Typen gemeinsam benutzten Optionen und
\fBsystemd.service\fP(5), \fBsystemd.socket\fP(5), \fBsystemd.swap\fP(5) und
\fBsystemd.mount\fP(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\&
.PP
Zusätzlich werden Optionen, die verfügbare Ressourcen mittels Linux Control
Groups (cgroups) steuern, in \fBsystemd.resource\-control\fP(5)
aufgeführt\&. Diese Optionen ergänzen die hier aufgeführten Optionen\&.
.SH "IMPLIZITE ABHÄNGIGKEITEN"
.PP
Ein paar Ausführungsparameter führen zur Ergänzung von zusätzlichen,
automatischen Abhängigkeiten:
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Units mit gesetzten \fIWorkingDirectory=\fP, \fIRootDirectory=\fP, \fIRootImage=\fP,
\fIRuntimeDirectory=\fP, \fIStateDirectory=\fP, \fICacheDirectory=\fP,
\fILogsDirectory=\fP oder \fIConfigurationDirectory=\fP erhalten automatisch
Abhängigkeiten vom Typ \fIRequires=\fP und \fIAfter=\fP von allen für den Zugriff
auf die festgelegten Pfade notwendigen Einhängepunkten\&. Dies ist
äquivalent zur expliziten Auflistung in \fIRequiresMountsFor=\fP\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Ähnlich erhalten Einhänge\-Units mit aktiviertem \fIPrivateTmp=\fP automatisch
Abhängigkeiten von allen Einhängungen, die notwendig sind, auf /tmp und
/var/tmp zuzugreifen\&. Sie werden auch automatische Abhängigkeiten
\fIAfter=\fP von \fBsystemd\-tmpfiles\-setup.service\fP(8) erhalten\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Units, deren Standardausgabe oder Fehlerausgabe mit dem \fBjournal\fP,
\fBsyslog\fP oder \fBkmsg\fP (oder ihrer Kombination mit Konsolenausgabe, siehe
unten) verbunden ist, erlangen automatisch Abhängigkeiten vom Typ \fIAfter=\fP
von systemd\-journald\&.socket\&.
.RE
.SH PFADE
.PP
Die folgenden Einstellungen können zur Änderungen 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\&.
.PP
\fIWorkingDirectory=\fP
.RS 4
Akzeptiert einen Verzeichnispfad, der relativ zu dem durch \fIRootDirectory=\fP
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 \fIUser=\fP 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
\fIRootDirectory=\fP/\fIRootImage=\fP nicht gesetzt ist, dann ist
\fIWorkingDirectory=\fP 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\&.
.RE
.PP
\fIRootDirectory=\fP
.RS 4
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 \fBchroot\fP(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
\fBchroot()\fP\-Gefängnis verfügbar sind\&. Beachten Sie, dass das Setzen dieses
Parameters die Hinzunahme von zusätzlichen Abhängigkeiten (siehe oben)
auslösen kann\&.
.sp
Die Einstellungen \fIMountAPIVFS=\fP und \fIPrivateUsers=\fP sind inbesondere in
Zusammenhang mit \fIRootDirectory=\fP nützlich\&. Für Details siehe unten\&.
.RE
.PP
\fIRootImage=\fP
.RS 4
Akzeptiert einen Pfad zu einem Blockgeräteknoten oder einer regulären Datei
als Argument\&. Dieser Aufruf ist ähnlich \fIRootDirectory=\fP, 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 \m[blue]\fBSpezifikation für auffindbare
Partitionen\fP\m[]\&\s-2\u[1]\d\s+2 folgt\&.
.sp
Wenn \fIDevicePolicy=\fP auf »closed« oder »strict« gesetzt ist oder auf »auto«
und \fIDeviceAllow=\fP gesetzt ist, dann fügt diese Einstellung
/dev/loop\-control mit Modus \fBrw\fP, »block\-loop« und »block\-blkext« mit Modus
\fBrwm\fP zu \fIDeviceAllow=\fP hinzu\&. Siehe \fBsystemd.resource\-control\fP(5) für
die Details über \fIDevicePolicy=\fP oder \fIDeviceAllow=\fP\&. Siehe auch
nachfolgendes \fIPrivateDevices=\fP, da sie die Einstellungen von
\fIDevicePolicy=\fP ändern könnte\&.
.RE
.PP
\fIMountAPIVFS=\fP
.RS 4
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 \fIRootDirectory=\fP/\fIRootImage=\fP 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
\fIPrivateDevices=\fP verwandt wird\&. Um den Dienst mit einer privaten,
minimalen Version von /dev/ auszuführen, kombinieren Sie diese Option mit
\fIPrivateDevices=\fP\&.
.RE
.PP
\fIBindPaths=\fP, \fIBindReadOnlyPaths=\fP
.RS 4
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\&.
.sp
\fIBindPaths=\fP erstellt reguläre, schreibbare Bind\-Einhängungen (außer die
Quelldateisystemeinhängung ist bereits nur\-lesbar markiert), während
\fIBindReadOnlyPaths=\fP 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\&.
.sp
Diese Option ist besonders nützlich, wenn \fIRootDirectory=\fP/\fIRootImage=\fP
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\&.
.RE
.SH ZUGANGSDATEN
.PP
\fIUser=\fP, \fIGroup=\fP
.RS 4
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 \fBsystemd \-\-user\fP verwaltet werden) ist die Vorgabe »root«, aber
\fIUser=\fP 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 gleiche Benutzer wie 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\&.
.sp
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\&.
.sp
Wenn dies zusammen mit \fIDynamicUser=\fP verwandt wird, wird der festgelegte
Benutzer\-/Gruppename dynamisch zum Startzeitpunkt des Dienstes zugewiesen
und beim Beenden des Dienstes wieder freigegeben \(em außer er ist bereits
statisch zugewiesen (siehe unten)\&. Falls \fIDynamicUser=\fP 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 \fBsysusers.d\fP(5), die beim
Systemstart oder zum Zeitpunkt der Paketinstallation angewandt wird\&.
.RE
.PP
\fIDynamicUser=\fP
.RS 4
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 \fBnss\-systemd\fP(8) stellt eine
Integration dieser dynamischen Benutzer/Gruppen in die Benutzer\- und
Gruppendatenbanken des Systems bereit\&. Die Benutzer\- und Gruppennamen
können mit \fIUser=\fP und \fIGroup=\fP (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 \fIUser=\fP 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 \fIGroup=\fP 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 \fIDynamicUser=\fP impliziert \fIRemoveIPC=\fP und
\fIPrivateTmp=\fP\&. 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 weltschreibbaren Verzeichnisse auf einem System
sind, stellt dies sicher, dass eine Unit, die dynamische
Benutzer\-/Gruppenzuweisungen einsetzt, keine Dateien nach der Beendigung
hinterlassen kann\&. Desweiteren sind \fIProtectSystem=strict\fP und
\fIProtectHome=read\-only\fP 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 \fIReadWritePaths=\fP
explizit erlaubt werden; dabei ist drauf zu achten, dass die Wiederbenutzung
von UIDs/GIDs keine Sicherheitsprobleme mit vom Dienst erstellten Dateien
hervorruft\&. Verwenden Sie \fIRuntimeDirectory=\fP (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 \fIStateDirectory=\fP,
\fICacheDirectory=\fP und \fILogsDirectory=\fP, 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)\&. Standardmäßig »off«\&.
.RE
.PP
\fISupplementaryGroups=\fP
.RS 4
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 keinen Effekt zeigen\&. 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\&.
.RE
.PP
\fIPAMName=\fP
.RS 4
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 \fIUser=\fP nützlich und wird sonst ignoriert\&. Falls nicht
gesetzt, wird keine PAM\-Sitzung für den ausgeführten Prozess
eröffnet\&. Siehe \fBpam\fP(8) für Details\&.
.sp
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\&.
.sp
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 \fIPAMName=\fP 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 \fINotifyAccess=\fP\fBall\fP 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,
\fIPAMName=\fP in Kombination mit \fINotifyAccess=\fP\fBall\fP zu verwenden\&.
.RE
.SH CAPABILITIES
.PP
\fICapabilityBoundingSet=\fP
.RS 4
Steuert, welche Capabilities in der Capability\-Begrenzungsmenge für den
ausgeführten Prozess aufgenommen werden\&. Siehe \fBcapabilities\fP(7) für
Details\&. Akzeptiert eine Leerzeichen\-getrennte Liste von Capability\-Namen,
z\&.B\&. \fBCAP_SYS_ADMIN\fP, \fBCAP_DAC_OVERRIDE\fP,
\fBCAP_SYS_PTRACE\fP\&. 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 \fBODER\fP zusammengeführt
oder mit \fBUND\fP, falls den Zeilen »~« vorangestellt wird (siehe
unten)\&. Falls die leere Zeichenkette dieser Option 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\&.
.sp
Beispiel: Falls eine Unit die Einstellunng
.sp
.if  n \{\
.RS 4
.\}
.nf
CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=CAP_B CAP_C
.fi
.if  n \{\
.RE
.\}
.sp
hat, dann werden \fBCAP_A\fP, \fBCAP_B\fP und \fBCAP_C\fP gesetzt\&. Falls der
zweiten Zeile »~« vorangestellt wird, d\&.h\&.
.sp
.if  n \{\
.RS 4
.\}
.nf
CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=~CAP_B CAP_C
.fi
.if  n \{\
.RE
.\}
.sp
dann wird nur \fBCAP_A\fP gesetzt\&.
.RE
.PP
\fIAmbientCapabilities=\fP
.RS 4
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\&. \fBCAP_SYS_ADMIN\fP,
\fBCAP_DAC_OVERRIDE\fP, \fBCAP_SYS_PTRACE\fP\&. Diese Option kann mehr als einmal
auftauchen, die Umgebungsmengen werden zusammengeführt (siehe Beispiele oben
in \fICapabilityBoundingSet=\fP)\&. 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\&.
.sp
Umgebungs\-Capabilitymengen sind nützlich, falls Sie einen Prozess als nicht
privilegierten Benutzer ausführen wollen, ihm aber dennoch einige
Capabilities geben möchten\&. Beachten Sie, dass in diesem Fall die Option
\fBkeep\-caps\fP automatisch zu \fISecureBits=\fP hinzugefügt ist, um die
Capabilities über den Benutzerwechsel hinweg zu
erhalten\&. \fIAmbientCapabilities=\fP betrifft keine Befehle, denen »+«
vorangestellt ist\&.
.RE
.SH SICHERHEIT
.PP
\fINoNewPrivileges=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls wahr, wird sichergestellt, dass
der Diensteprozess und sämtliche seiner Kinder niemals mittels \fBexecve()\fP
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 \fISystemCallFilter=\fP,
\fISystemCallArchitectures=\fP, \fIRestrictAddressFamilies=\fP,
\fIRestrictNamespaces=\fP, \fIPrivateDevices=\fP, \fIProtectKernelTunables=\fP,
\fIProtectKernelModules=\fP, \fIMemoryDenyWriteExecute=\fP, \fIRestrictRealtime=\fP
oder \fILockPersonality=\fP festgelegt werden\&. Beachten Sie, dass selbst
diese Einstellung durch sie außer Kraft gesetzt wird, \fBsystemctl show\fP
zeigt den ursprünglichen Wert dieser Einstellung\&. Siehe auch
\m[blue]\fBSchalter »Keine neuen Privilegien«\fP\m[]\&\s-2\u[2]\d\s+2\&.
.RE
.PP
\fISecureBits=\fP
.RS 4
Steuert die Menge der sicheren Bits für den ausgeführten
Prozess\&. Akzeptiert eine durch Leerzeichen getrennte Kombination von
Optionen aus der folgenden Liste: \fBkeep\-caps\fP, \fBkeep\-caps\-locked\fP,
\fBno\-setuid\-fixup\fP, \fBno\-setuid\-fixup\-locked\fP, \fBnoroot\fP und
\fBnoroot\-locked\fP\&. 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
\fBcapabilities\fP(7) für Details\&.
.RE
.SH "MANDATORY ACCESS CONTROL"
.PP
\fISELinuxContext=\fP
.RS 4
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 sind\&. Siehe \fBsetexeccon\fP(3) für
Details\&.
.RE
.PP
\fIAppArmorProfile=\fP
.RS 4
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 sind\&.
.RE
.PP
\fISmackProcessLabel=\fP
.RS 4
Akzeptiert eine \fBSMACK64\fP\-Sicherheitskennzeichnung als Argument\&. Der
durch diese Unit ausgeführte Prozess wird unter dieser Kennzeichnung
gestartet und SMACK wird darauf basierend entscheiden, ob die Ausführung des
Prozesses erlaubt ist\&. Der Prozess wird weiter unter der hier festgelegten
Kennzeichnung laufen, außer falls das Programm seine eigene
\fBSMACK64EXEC\fP\-Kennzeichnung hat, in welchem Falle der Prozess dazu
übergehen wird, unter dieser Kennzeichnung zu laufen\&. Falls nicht
angegeben wird die Kennzeichnung verwandt, unter der Systemd läuft\&. Diese
Anweisung wird ignoriert, falls SMACK deaktiviert ist\&.
.sp
Diesem Wert kann »\-« vorangestellt werden, wodurch alle Fehler ignoriert
werden\&. Ein leerer Wert kann festgelegt werden, um alle vorhergehenden
Zuweisungen zurückzusetzen\&. Dies betrifft nicht Befehle, denen »+«
vorangestellt ist\&.
.RE
.SH PROZESSEIGENSCHAFTEN
.PP
\fILimitCPU=\fP, \fILimitFSIZE=\fP, \fILimitDATA=\fP, \fILimitSTACK=\fP, \fILimitCORE=\fP,
\fILimitRSS=\fP, \fILimitNOFILE=\fP, \fILimitAS=\fP, \fILimitNPROC=\fP,
\fILimitMEMLOCK=\fP, \fILimitLOCKS=\fP, \fILimitSIGPENDING=\fP, \fILimitMSGQUEUE=\fP,
\fILimitNICE=\fP, \fILimitRTPRIO=\fP, \fILimitRTTIME=\fP
.RS 4
Setzt die weichen und harten Beschränkungen für verschiedene Ressourcen für
ausgeführte Prozesse\&. Siehe \fBsetrlimit\fP(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 \fBweich:hart\fP, um beide Begrenzungen individuell
zu setzen (z\&.B\&. »LimitAS=4G:16G«)\&. Verwenden Sie die Zeichenkette
\fBinfinity\fP, 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 \fBsystemd.time\fP(7) für
Details)\&. Beachten Sie, dass die Standardzeiteinheit als Sekunden
impliziert ist, falls keine Zeiteinheit für \fILimitCPU=\fP angegeben
ist\&. Für \fILimitRTTIME=\fP wird als Standardeinheit Mikrosekunden
impliziert\&. Beachten Sie, dass die effektive Granularität der Begrenzungen
ihre Durchsetzung beeinflussen könnte\&. Beispielsweise werden für
\fILimitCPU=\fP festgelegte Zeitbeschränkungen implizit auf Vielfache von 1s
aufgerundet\&. Für \fILimitNICE=\fP 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
Ressourenbegrenzungsparameter im Bereich 0\&.\&.40 (wobei 0 äquivalent zu 1
ist) verstanden\&.
.sp
Beachten Sie, dass die meisten der mit diesen Optionen konfigurierten
Ressourcenbeschränkungen prozessbezogen sind und dass Prozesse einen Fork
durchführen können, um einen neuen Satz an Ressourcen zu erlangen, die
unabhängig vom ursprünglichen Prozess verbucht werden und daher gesetzten
Beschränkungen entkommen können\&. Beachten Sie auch, dass \fILimitRSS=\fP
unter Linux nicht implementiert ist und das Setzen keinen Effekt hat\&. Oft
ist es ratsam, die in \fBsystemd.resource\-control\fP(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 \fIMemoryLimit=\fP ein
leistungsfähigerer (und funktionierender) Ersatz für \fILimitRSS=\fP\&.
.sp
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 \fBsystemd\fP(1) ausgeführt werden) wird allerdings eine
Begrenzungen durch (möglicherweise weiter eingeschränkte) benutzerbezogene
Einschränkungen durch das Betriebssystem erzwungen\&.
.sp
Nicht explizit konfigurierte Ressourcenbeschränkungen für eine Unit
verwenden als Vorgabe die in den verschiedenen in \fBsystemd\-system.conf\fP(5)
verfügbare Optionen \fIDefaultLimitCPU=\fP, \fIDefaultLimitFSIZE=\fP, …
konfigurierten Werte und \(en falls sie dort nicht konfiguriert sind \(en
die Kernel\- oder benutzerbezogenen Vorgaben, wie sie durch das
Betriebssystem (letzteres nur für Benutzerdienste, siehe oben) definiert
sind\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&1.\ \&Ressourcenbegrenzungsanweisungen, ihre äquivalenten
Ulimit\-Shell\-Befehle und die verwandte Einheit\fP
.TS
allbox tab(:);
lB lB lB.
T{
Anweisung
T}:T{
\fBulimit\fP\-Äquivalent
T}:T{
Einheit
T}
.T&
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l.
T{
LimitCPU=
T}:T{
ulimit \-t
T}:T{
Sekunden
T}
T{
LimitFSIZE=
T}:T{
ulimit \-f
T}:T{
Bytes
T}
T{
LimitDATA=
T}:T{
ulimit \-d
T}:T{
Bytes
T}
T{
LimitSTACK=
T}:T{
ulimit \-s
T}:T{
Bytes
T}
T{
LimitCORE=
T}:T{
ulimit \-c
T}:T{
Bytes
T}
T{
LimitRSS=
T}:T{
ulimit \-m
T}:T{
Bytes
T}
T{
LimitNOFILE=
T}:T{
ulimit \-n
T}:T{
Anzahl an Dateideskriptoren
T}
T{
LimitAS=
T}:T{
ulimit \-v
T}:T{
Bytes
T}
T{
LimitNPROC=
T}:T{
ulimit \-u
T}:T{
Anzahl an Prozessen
T}
T{
LimitMEMLOCK=
T}:T{
ulimit \-l
T}:T{
Bytes
T}
T{
LimitLOCKS=
T}:T{
ulimit \-x
T}:T{
Anzahl an Sperren
T}
T{
LimitSIGPENDING=
T}:T{
ulimit \-i
T}:T{
Anzahl von Signalen in der Warteschlange
T}
T{
LimitMSGQUEUE=
T}:T{
ulimit \-q
T}:T{
Bytes
T}
T{
LimitNICE=
T}:T{
ulimit \-e
T}:T{
Nice\-Stufe
T}
T{
LimitRTPRIO=
T}:T{
ulimit \-r
T}:T{
Echtzeitpriorität
T}
T{
LimitRTTIME=
T}:T{
Kein Äquivalent
T}:T{
Mikrosekunden
T}
.TE
.sp 1
.RE
.PP
\fIUMask=\fP
.RS 4
Steuert die Dateimoduserstellungsmaske\&. Akzeptiert einen Zugriffsmodus in
oktaler Notation\&. Siehe \fBumask\fP(2) für Details\&. Standardmäßig 0022\&.
.RE
.PP
\fIKeyringMode=\fP
.RS 4
Steuert, wie das Kernelsitzungsschlüsselbund für den Dienst eingerichtet
wird (siehe \fBsession\-keyring\fP(7) für Details über den
Sitzungsschlüsselbund)\&. Akzeptiert einen aus \fBinherit\fP, \fBprivate\fP,
\fBshared\fP\&. Falls auf \fBinherit\fP gesetzt, wird keine besondere
Schlüsselbundeinrichtung vorgenommen und das Standardverhalten des Kernels
wird angewandt\&. Falls \fBprivate\fP 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 \fBshared\fP verwandt wird, wird ein neuer Schlüsselbund wie
für \fBprivate\fP reserviert, aber der Benutzerschlüsselbund des mit \fIUser=\fP
konfigurierten Benutzers wird mit hineingebunden, 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 \fBinherit\fP 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 \fBprivate\fP für Dienste des
Systemdiensteverwalters und \fBinherit\fP für nicht Dienste\-Units und für
Dienste des Benutzerdiensteverwalters\&.
.RE
.PP
\fIOOMScoreAdjust=\fP
.RS 4
Sets the adjustment level for the Out\-Of\-Memory killer for executed
processes\&. Takes an integer between \-1000 (to disable OOM killing for this
process) and 1000 (to make killing of this process under memory pressure
very likely)\&. See \m[blue]\fBproc\&.txt\fP\m[]\&\s-2\u[3]\d\s+2 for
details\&.
.RE
.PP
\fITimerSlackNSec=\fP
.RS 4
Sets the timer slack in nanoseconds for the executed processes\&. The timer
slack controls the accuracy of wake\-ups triggered by timers\&. See
\fBprctl\fP(2)  for more information\&. Note that in contrast to most other
time span definitions this parameter takes an integer value in nano\-seconds
if no unit is specified\&. The usual time units are understood too\&.
.RE
.PP
\fIPersonality=\fP
.RS 4
Steuert, welche Kernelarchitektur \fBuname\fP(2) berichten soll, wenn er von
Unit\-Prozessen aufgerufen wird\&. Akzeptiert eine der Architekturkennungen
\fBx86\fP, \fBx86\-64\fP, \fBppc\fP, \fBppc\-le\fP, \fBppc64\fP, \fBppc64\-le\fP, \fBs390\fP oder
\fBs390x\fP\&. 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 \fBx86\-64\fP\-Systeme die \fBx86\-64\fP\- und \fBx86\fP\-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\&.
.RE
.PP
\fIIgnoreSIGPIPE=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls wahr, wird \fBSIGPIPE\fP in dem
ausgeführten Prozess ignoriert\&. Standardmäßig wahr, da \fBSIGPIPE\fP im
Allgemeinen nur in Shell\-Pipes nützlich ist\&.
.RE
.SH SCHEDULING
.PP
\fINice=\fP
.RS 4
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 \fBsetpriority\fP(2) für Details\&.
.RE
.PP
\fICPUSchedulingPolicy=\fP
.RS 4
Setzt die CPU\-Scheduling\-Richtlinie für ausgeführte Prozesse\&. Akzeptiert
eines aus \fBother\fP, \fBbatch\fP, \fBidle\fP, \fBfifo\fP, \fBrr\fP\&. Siehe
\fBsched_setscheduler\fP(2) für Details\&.
.RE
.PP
\fICPUSchedulingPriority=\fP
.RS 4
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
\fBsched_setscheduler\fP(2) für Details\&.
.RE
.PP
\fICPUSchedulingResetOnFork=\fP
.RS 4
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 \fBsched_setscheduler\fP(2) für Details\&. Standardmäßig
falsch\&.
.RE
.PP
\fICPUAffinity=\fP
.RS 4
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 \fBsched_setaffinity\fP(2) für
Details\&.
.RE
.PP
\fIIOSchedulingClass=\fP
.RS 4
Setzt die E/A\-Scheduling\-Klasse für ausgeführte Prozesse\&. Akzeptiert eine
Ganzzahl zwischen 0 und 3 oder eine der Zeichenketten \fBnone\fP, \fBrealtime\fP,
\fBbest\-effort\fP oder \fBidle\fP\&. Falls dieser Option die leere Zeichenkette
zugewiesen wird, haben alle vorhergehenden Zuweisungen zu
\fIIOSchedulingClass=\fP und \fIIOSchedulingPriority=\fP keinen Effekt\&. Siehe
\fBioprio_set\fP(2) für Details\&.
.RE
.PP
\fIIOSchedulingPriority=\fP
.RS 4
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
\fIIOSchedulingClass=\fP und \fIIOSchedulingPriority=\fP keinen Effekt\&. Siehe
\fBioprio_set\fP(2) für Details\&.
.RE
.SH SANDBOXING
.PP
Die nachfolgenden Sandboxing\-Optionen bieten eine wirksame Art, die Kontakte
des System 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 \fIProtectSystem=\fP 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 \fIRestrictRealtime=\fP 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\&.
.PP
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 \fIProtectSystem=\fP) sind nicht
verfügbar, da die zugrundeliegende Kernelfunktionalität nur für
privilegierte Prozesse erreichbar ist\&.
.PP
\fIProtectSystem=\fP
.RS 4
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 \fIPrivateDevices=\fP,
\fIProtectKernelTunables=\fP, \fIProtectControlGroups=\fP)\&. 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
\fIReadWritePaths=\fP verwandt werden, um bestimmte Verzeichnisse von dem nur
lesbaren Verhalten auszunehmen\&. Diese Einstellung ist impliziert, falls
\fIDynamicUser=\fP gesetzt ist\&. Diese Einstellung kann nicht für alle Fälle
den Schutz sicherstellen\&. Im Allgemeinen hat es die gleichen Begrenzungen
wie \fIReadOnlyPaths=\fP, siehe unten\&. Standardmäßig aus\&.
.RE
.PP
\fIProtectHome=\fP
.RS 4
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 notwendige Verzeichnisse weiterhin sichtbar sind, indem mit
\fIBindPaths=\fP oder \fIBindReadOnlyPaths=\fP kombiniert wird\&.
.sp
Setzen dieser Einstellung auf »yes« ist fast äquivalent zum Setzen der drei
Verzeichnisse in \fIInaccessiblePaths=\fP\&. Ähnlich ist »read\-only« fast
äquivalent zu \fIReadOnlyPaths=\fP und »tmpfs« ist fast äquivalent zu
\fITemporaryFileSystem=\fP\&.
.sp
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 \fIDynamicUser=\fP gesetzt ist\&. Diese Einstellung kann
nicht für alle Fälle den Schutz sicherstellen\&. Im Allgemeinen hat es die
gleichen Begrenzungen wie \fIReadOnlyPaths=\fP, siehe unten\&.
.RE
.PP
\fIRuntimeDirectory=\fP, \fIStateDirectory=\fP, \fICacheDirectory=\fP,
\fILogsDirectory=\fP, \fIConfigurationDirectory=\fP
.RS 4
Diese Optionen akzeptieren eine Leeraum 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 (»:«) zusammengehängt\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&2.\ \&Automatische Verzeichniserstellung und
Umgebungsvariablen\fP
.TS
allbox tab(:);
lB lB lB lB.
T{
Ort
T}:T{
fürs System
T}:T{
für Benutzer
T}:T{
Umgebungsvariable
T}
.T&
l l l l
l l l l
l l l l
l l l l
l l l l.
T{
\fIRuntimeDirectory=\fP
T}:T{
/run
T}:T{
\fI$XDG_RUNTIME_DIR\fP
T}:T{
\fI$RUNTIME_DIRECTORY\fP
T}
T{
\fIStateDirectory=\fP
T}:T{
/var/lib
T}:T{
\fI$XDG_CONFIG_HOME\fP
T}:T{
\fI$STATE_DIRECTORY\fP
T}
T{
\fICacheDirectory=\fP
T}:T{
/var/cache
T}:T{
\fI$XDG_CACHE_HOME\fP
T}:T{
\fI$CACHE_DIRECTORY\fP
T}
T{
\fILogsDirectory=\fP
T}:T{
/var/log
T}:T{
\fI$XDG_CONFIG_HOME\fP/log
T}:T{
\fI$LOGS_DIRECTORY\fP
T}
T{
\fIConfigurationDirectory=\fP
T}:T{
/etc
T}:T{
\fI$XDG_CONFIG_HOME\fP
T}:T{
\fI$CONFIGURATION_DIRECTORY\fP
T}
.TE
.sp 1
Im Falle von \fIRuntimeDirectory=\fP werden die tiefsten Unterverzeichnisse
entfernt, wenn die Unit gestoppt wird\&. Es ist möglich, in diesem Fall die
festgelegten Verzeichnisse zu erhalten, falls \fIRuntimeDirectoryPreserve=\fP
auf \fBrestart\fP oder \fByes\fP konfiguriert ist (siehe unten)\&. Die mit
\fIStateDirectory=\fP, \fICacheDirectory=\fP, \fILogsDirectory=\fP,
\fIConfigurationDirectory=\fP festgelegten Verzeichnisse werden nicht entfernt,
wenn die Unit gestoppt wird\&.
.sp
Außer im Fall von \fIConfigurationDirectory=\fP werden die innersten
festgelegten Verzeichnisse dem in \fIUser=\fP und \fIGroup=\fP 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 \fIRuntimeDirectoryMode=\fP,
\fIStateDirectoryMode=\fP, \fICacheDirectoryMode=\fP, \fILogsDirectoryMode=\fP und
\fIConfigurationDirectoryMode=\fP festgelegt ist, angepasst\&.
.sp
Diese Optionen implizieren \fIBindPaths=\fP für die festgelegten Pfade\&. Bei
der Kombination mit \fIRootDirectory=\fP oder \fIRootImage=\fP werden diese Pfade
immer innerhalb des Rechners liegen und von dort in den
Dateisystemnamensraum der Unit eingehängt\&.
.sp
Falls \fIDynamicUser=\fP zusammen mit \fIStateDirectory=\fP, \fICacheDirectory=\fP
und \fILogsDirectory=\fP 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 das Recyclen
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\&.
.sp
Verwenden Sie \fIRuntimeDirectory=\fP, 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
\fBtmpfiles.d\fP(5)\&.
.sp
Beispiel: Falls eine Systemdienste\-Unit
.sp
.if  n \{\
.RS 4
.\}
.nf
RuntimeDirectory=foo/bar baz
.fi
.if  n \{\
.RE
.\}
.sp
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 \fIUser=\fP
und \fIGroup=\fP festgelegt sind und werden entfernt, wenn der Dienst gestoppt
wird\&.
.sp
Beispiel: Falls eine Systemdienste\-Unit
.sp
.if  n \{\
.RS 4
.\}
.nf
RuntimeDirectory=foo/bar
StateDirectory=aaa/bbb ccc
.fi
.if  n \{\
.RE
.\}
.sp
enthält, dann wird die Umgebungsvariable »RUNTIME_DIRECTORY« mit
»/run/foo/bar« und »STATE_DIRECTORY« mit »/var/lib/aaa/bbb:/var/lib/ccc«
gesetzt\&.
.RE
.PP
\fIRuntimeDirectoryMode=\fP, \fIStateDirectoryMode=\fP, \fICacheDirectoryMode=\fP,
\fILogsDirectoryMode=\fP, \fIConfigurationDirectoryMode=\fP
.RS 4
Legt die Zugriffsmodi der in \fIRuntimeDirectory=\fP, \fIStateDirectory=\fP,
\fICacheDirectory=\fP, \fILogsDirectory=\fP bezw. \fIConfigurationDirectory=\fP
festgelegten Verzeichnisse in einer oktalen Zahl fest\&. Standardmäßig
\fB0755\fP\&. Siehe »Permissions« in \fBpath_resolution\fP(7) für eine Diskussion
über die Benennung der Berechtigungs\-Bits\&.
.RE
.PP
\fIRuntimeDirectoryPreserve=\fP
.RS 4
Akzeptiert ein logisches Argument oder \fBrestart\fP\&. Falls auf die Vorgabe
\fBno\fP gesetzt, werden die in \fIRuntimeDirectory=\fP festgelegten Verzeichnisse
immer entfernt, wenn der Dienst beendet wird\&. Falls auf \fBrestart\fP
gesetzt, werden die Verzeichnisse erhalten, wenn der Dienst sowohl
automatisch als auch manuell neu gestartet wird\&. Hier bedeutet der
automatische Neustart die in \fIRestart=\fP festgelegte Aktion und manueller
Neustart bedeutet die durch \fBsystemctl restart foo\&.service\fP
ausgelöste\&. Falls auf \fIyes\fP gesetzt, werden die Verzeichnisse nicht
entfernt, wenn der Dienst beendet wird\&. Beachten Sie, dass die in
\fIRuntimeDirectory=\fP festgelegten Verzeichnisse entfernt werden, wenn das
System neu gestartet wird, da das Laufzeitverzeichnis /run ein
»tmpfs«\-Einhängepunkt ist\&.
.RE
.PP
\fIReadWritePaths=\fP, \fIReadOnlyPaths=\fP, \fIInaccessiblePaths=\fP
.RS 4
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 \fIRootDirectory=\fP/\fIRootImage=\fP gesetzten Wurzelverzeichnis
aufgelöst werden, falls sie Symlinks enthalten\&.
.sp
In \fIReadWritePaths=\fP aufgeführte Pfade sind von innerhalb des Namensraums
mit den gleichen Zugriffsmodi wie von außerhalb zugreifbar\&. In
\fIReadOnlyPaths=\fP aufgeführte Pfade sind nur lesbar zugreifbar, Schreiben
wird abgelehnt, selbst falls die normale Dateizugriffssteuerung dies
erlauben würde\&. Schachteln Sie \fIReadWritePaths=\fP innerhalb von
\fIReadOnlyPaths=\fP, um schreibbare Unterverzeichnisse innerhalb nur lesbarer
Verzeichnisse bereitzustellen\&. Verwenden Sie \fIReadWritePaths=\fP, um
bestimmte Pfade für den Schreibzugriff freizuschalten, falls
\fIProtectSystem=strict\fP verwandt wird\&.
.sp
In \fIInaccessiblePaths=\fP 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 \fIReadWritePaths=\fP, \fIReadOnlyPaths=\fP,
\fIBindPaths=\fP oder \fIBindReadOnlyPaths=\fP zu verschachteln\&. Für eine
flexiblere Option siehe \fITemporaryFileSystem=\fP\&.
.sp
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\&.
.sp
Pfaden in \fIReadWritePaths=\fP, \fIReadOnlyPaths=\fP und \fIInaccessiblePaths=\fP
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
\fIRootDirectory=\fP/\fIRootImage=\fP konfiguriert ist, statt relativ zum
Wurzelverzeichnis des Rechners (siehe oben)\&. Wenn Sie »\-« und »+« auf dem
gleichen Pfad kombinieren, verwenden Sie »\-« zuerst und danach »+«\&.
.sp
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
\fIReadWritePaths=\fP\- und \fIReadOnlyPaths=\fP\-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 fortgepflanzt werden, der mit \fIReadOnlyPaths=\fP 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
Verriegelung nicht vollständig ist und keinen vollständigen Schutz bietet\&.
.sp
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 \fICapabilityBoundingSet=~CAP_SYS_ADMIN\fP oder
\fISystemCallFilter=~@mount\fP zu kombinieren\&.
.RE
.PP
\fITemporaryFileSystem=\fP
.RS 4
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«\&.
.sp
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 \fIBindPaths=\fP
oder \fIBindReadOnlyPaths=\fP weiterhin zugegriffen werden kann\&. Siehe das
nachfolgende Beispiel\&.
.sp
Beispiel: Falls eine Unit die Einstellunng
.sp
.if  n \{\
.RS 4
.\}
.nf
TemporaryFileSystem=/var:ro
BindReadOnlyPaths=/var/lib/systemd
.fi
.if  n \{\
.RE
.\}
.sp
Der durch die Unit aufgerufene Prozess kann dann keine Dateien,
Verzeichnisse oder Inhalte unter /var außer /var/lib/systemd sehen\&.
.RE
.PP
\fIPrivateTmp=\fP
.RS 4
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 \fIJoinsNamespaceOf=\fP zu benutzen, siehe
\fBsystemd.unit\fP(5) für Details\&. Diese Einstellung ist impliziert, falls
\fIDynamicUser=\fP gesetzt ist\&. Für diese Einstellung gelten die gleichen
Beschränkungen bezüglich Einhängeausbreitung und Privilegien wie für
\fIReadOnlyPaths=\fP und verwandte Aufrufe, siehe oben\&. Aktivieren dieser
Einstellung hat den Seiteneffekt des Hinzufügens der Abhängigkeiten
\fIRequires=\fP und \fIAfter=\fP zu allen für den Zugriff auf /tmp und /var/tmp
notwendigen Einhänge\-Units\&. Desweiteren wird eine implizite
\fIAfter=\fP\-Ordnung auf \fBsystemd\-tmpfiles\-setup.service\fP(8) hinzugefügt\&.
.sp
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\&.
.RE
.PP
\fIPrivateDevices=\fP
.RS 4
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/men, 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 \fI@raw\-io\fP versammelt sind, zu blockieren, \fBCAP_MKNOD\fP und
\fBCAP_SYS_RAWIO\fP aus der Capability\-Begrenzungsmenge für die Unit (siehe
oben) zu entfernen und \fIDevicePolicy=closed\fP zu setzen (siehe
\fBsystemd.resource\-control\fP(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
\fBmmap\fP(2) aus /dev/zero ausführbaren Speicher einrichten, statt \fBMAP_ANON\fP
zu verwenden\&. Für diese Einstellung gelten die gleichen Einschränkungen im
Hinblick auf Einhängeausbreitung und Privilegien wie für \fIReadOnlyPaths=\fP
und verwandte Aufrufe, siehe oben\&. Falls dies eingeschaltet und im
Benutzermodus oder im Systemmodus aber ohne die Capability \fBCAP_SYS_ADMIN\fP
(z\&.B\&. durch Setzen von \fIUser=\fP) betrieben wird, wird
\fINoNewPrivileges=yes\fP impliziert\&.
.sp
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\&.
.RE
.PP
\fIPrivateNetwork=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls war, 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 \fIJoinsNamespaceOf=\fP zu
benutzen, siehe \fBsystemd.unit\fP(5) für Details\&. Beachten Sie, dass diese
Option alle Socket\-Einrichtungen, einschließlich \fBAF_NETLINK\fP und
\fBAF_UNIX\fP, vom Rechner trennen wird\&. Effektiv bedeutet das für
\fBAF_NETLINK\fP, dass von \fBsystemd\-udevd.service\fP(8) empfangene
Gerätekonfigurationsereignisse nicht zu den Prozessen der Unit ausgeliefert
werden\&. Und für \fBAF_UNIX\fP hat dies den Effekt, dass \fBAF_UNIX\fP\-Sockets in
dem abstrakten Namensraum des Rechners für Prozesse der Unit unverfügbar
werden (allerdings werden solche im Dateisystem weiterhin zugreifbar
sein)\&.
.sp
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\&.
.RE
.PP
\fIPrivateUsers=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Richtet falls wahr einen neunen
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 benutzte 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 \fICapabilityBoundingSet=\fP beeinflussen nur
letzteren und es gibt keine Möglichkeit, zusätzliche Capabilities im
Benutzerraum des Systems zu erlangen\&. Standardmäßig aus\&.
.sp
Diese Einstellung ist insbesondere im Zusammenspiel mit
\fIRootDirectory=\fP/\fIRootImage=\fP 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\&.
.sp
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\&.
.RE
.PP
\fIProtectKernelTunables=\fP
.RS 4
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 \fBsysctl.d\fP(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
\fIReadOnlyPaths=\fP und verwandte Aufrufe, siehe oben\&. Standardmäßig
aus\&. Falls eingeschaltet und im Benutzermodus oder im Systemmodus aber
ohne die Capability \fBCAP_SYS_ADMIN\fP (d\&.h\&. für Dienste, bei denen
\fIUser=\fP gesetzt ist) betrieben, wird \fINoNewPrivileges=yes\fP
impliziert\&. Beachten Sie, dass diese Option keine indirekten Änderungen an
Kerneleinstellungen, die durch IPC\-Aufrufe an andere Prozesse erfolgen,
verhindert\&. Allerdings kann \fIInaccessiblePaths=\fP verwandt werden, um die
relevanten IPC\-Dateisystemobjekte unzugreifbar zu machen\&. Falls
\fIProtectKernelTunables=\fP gesetzt ist, wird \fIMountAPIVFS=yes\fP impliziert\&.
.RE
.PP
\fIProtectKernelModules=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls wahr, wird das explizite Laden
von Modulen verweigert\&. Dies erlaubt es, dass 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 \fBCAP_SYS_MODULE\fP aus der Capability\-Begrenzungsmenge
für die Unit und installiert ein 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 \fIReadOnlyPaths=\fP und verwandte
Aufrufe, siehe oben\&. Beachten Sie, dass begrenztes automatische Modulladen
aufgrund von Benutzerkonfiguration oder Kernelabbildungstabellen als
Seiteneffekt von angefragten Benutzeraktionen, sowohl privilegiert als auch
unprivilegiert, weiterhin vorkommen können\&. Um die Funktionalität des
automatischen Moduleladens zu deaktivieren, lesen Sie bitte die
Dokumentation zum Mechanismus \fBkernel\&.modules_disabled\fP von
\fBsysctl.d\fP(5) und /proc/sys/kernel/modules_disabled\&. Falls dies
eingeschaltet und im Benutzermodus oder im Systemmodus aber ohne die
Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=\fP) betrieben
wird, wird \fINoNewPrivileges=yes\fP impliziert\&.
.RE
.PP
\fIProtectControlGroups=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls wahr, werden die über
/sys/fs/cgroup erreichbaren »Linux Control Groups«
(\fBcgroups\fP(7))\-Hierarchie 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
\fIReadOnlyPaths=\fP und verwandte Aufrufe, siehe oben\&. Standardmäßig
aus\&. Falls \fIProtectControlGroups=\fP gesetzt ist, wird \fIMountAPIVFS=yes\fP
impliziert\&.
.RE
.PP
\fIRestrictAddressFamilies=\fP
.RS 4
Beschränkt die Gruppe der Socket\-Adressfamilien, auf die Prozesse dieser
Unit zugreifen können\&. Akzeptiert eine Leerzeichen\-getrennte Liste von
freizugebenen Adressfamiliennamen, wie \fBAF_UNIX\fP, \fBAF_INET\fP oder
\fBAF_INET6\fP\&. Wird dieser \fB~\fP vorangestellt, wird die Liste der
Adressfamilien als Ausschlussliste angewandt, andernfalls als
Freigabeliste\&. Beachten Sie, dass dies nur Zugriff auf den Systemaufruf
\fBsocket\fP(2) beschränkt\&. Sockets, die auf anderem Wege in die Unit
hereingegeben werden (beispielsweise durch Verwendung von Socket\-Aktivierung
mit Socket\-Units, siehe \fBsystemd.socket\fP(5)) sind davon nicht
betroffen\&. Auch Sockets, die mit \fBsocketpair()\fP (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
\fISystemCallArchitectures=native\fP oder ähnlichem zu kombinieren\&. Falls der
Betrieb im Benutzermodus oder im Systemmodus aber ohne die Capability
\fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=\fP) erfolgt, wird
\fINoNewPrivileges=yes\fP impliziert\&. Standardmäßig werden keine
Einschränkungen angewandt, Prozesse können auf alle Adressfamilien
zugreifen\&. Falls die leere Zeichenkette zugewiesen wird, werden alle
vorherigen Adressfamilieneinschränkungsänderungen zurückgenommen\&. Diese
Einstellung betrifft keine Befehle, denen »+« vorangestellt sind\&.
.sp
Verwenden Sie diese Option, um den Kontakt des Prozesses für Zugriff aus der
Ferne, insbesondere über exotische und heikle Netzwerkprotokolle wie
\fBAF_PACKET\fP, zu begrenzen\&. Beachten Sie, dass in den meisten Fällen die
lokale Adressfamilie \fBAF_UNIX\fP in die konfigurierte Freigabeliste
aufgenommen werden sollte, das sie häufig für lokale Kommunikation verwandt
wird, einschließlich für die \fBsyslog\fP(2)\-Protokollierung\&.
.RE
.PP
\fIRestrictNamespaces=\fP
.RS 4
Begrenzt Zugriff auf die Linux\-Namensraumfunktionalität für die Prozesse
dieser Unit\&. Für Details über Linux\-Namensräume siehe
\fBnamespaces\fP(7)\&. Akzeptiert entweder ein logische Argument oder eine
Leeraum\-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
\fBcgroup\fP, \fBipc\fP, \fBnet\fP, \fBmnt\fP, \fBpid\fP, \fBuser\fP und \fButs\fP
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 \fBODER\fP (oder mit \fBUND\fP, falls den Zeilen »~«
vorangestellt wird) zusammengefasst (siehe nachfolgende Beispiele)\&. Intern
begrenzt diese Einstellung Zugriff auf die Systemaufrufe \fBunshare\fP(2),
\fBclone\fP(2) und \fBsetns\fP(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 \fBsetns()\fP 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 \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von
\fIUser=\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&.
.sp
Beispiel: Falls eine Unit die Einstellunng
.sp
.if  n \{\
.RS 4
.\}
.nf
RestrictNamespaces=cgroup ipc
RestrictNamespaces=cgroup net
.fi
.if  n \{\
.RE
.\}
.sp
hat, dann werden \fBcgroup\fP, \fBipc\fP und \fBnet\fP gesetzt\&. Falls der zweiten
Zeile »~« vorangestellt wird, d\&.h\&.
.sp
.if  n \{\
.RS 4
.\}
.nf
RestrictNamespaces=cgroup ipc
RestrictNamespaces=~cgroup net
.fi
.if  n \{\
.RE
.\}
.sp
dann wird nur \fBipc\fP gesetzt\&.
.RE
.PP
\fILockPersonality=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls gesetzt, verriegelt es den
Systemaufruf \fBpersonality\fP(2), so dass die Kernel\-Ausführungsdomäne nicht
mehr von der Vorgabe oder von der mit der Anweisung \fIPersonality=\fP
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
\fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=\fP) erfolgt, wird
\fINoNewPrivileges=yes\fP impliziert\&.
.RE
.PP
\fIMemoryDenyWriteExecute=\fP
.RS 4
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 \fBmmap\fP(2)  system calls with both \fBPROT_EXEC\fP and
\fBPROT_WRITE\fP set, \fBmprotect\fP(2)  or \fBpkey_mprotect\fP(2)  system calls with
\fBPROT_EXEC\fP set and \fBshmat\fP(2)  system calls with \fBSHM_EXEC\fP 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 \fBnoexec\fP (such as /dev/shm), or it can use
\fBmemfd_create()\fP\&. This can be prevented by making such file systems
inaccessible to the service (e\&.g\&.  \fIInaccessiblePaths=/dev/shm\fP) and
installing further system call filters
(\fISystemCallFilter=~memfd_create\fP)\&. Note that this feature is fully
available on x86\-64, and partially on x86\&. Specifically, the \fBshmat()\fP
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 \fISystemCallArchitectures=native\fP or similar\&. If running
in user mode, or in system mode, but without the \fBCAP_SYS_ADMIN\fP capability
(e\&.g\&. setting \fIUser=\fP), \fINoNewPrivileges=yes\fP is implied\&.
.RE
.PP
\fIRestrictRealtime=\fP
.RS 4
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 \fBSCHED_FIFO\fP, \fBSCHED_RR\fP oder
\fBSCHED_DEADLINE\fP begrenzt\&. Siehe \fBsched\fP(7) für Details über diese
Scheduling\-Richtlinien\&. Falls der Betrieb im Benutzermodus oder im
Systemmodus aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen
von \fIUser=\fP) erfolgt, wird \fINoNewPrivileges=yes\fP
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 Zugiff auf Echtzeit\-Scheduling auf die wenigen Programme, die
dies tatsächlich benötigen, zu begrenzen\&. Standardmäßig aus\&.
.RE
.PP
\fIRemoveIPC=\fP
.RS 4
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 \fIUser=\fP, \fIGroup=\fP oder
\fIDynamicUser=\fP 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 \fIDynamicUser=\fP
gesetzt ist\&.
.RE
.PP
\fIPrivateMounts=\fP
.RS 4
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
\fBmount_namespaces\fP(7) für Details bezüglich
Dateisystemnamensräumen\&. Standardmäßig aus\&.
.sp
Falls eingeschaltet wird dies drei Aktionen für jeden aufgerufenen Prozess
auslösen: ein neuer \fBCLONE_NEWNS\fP\-Namensraum wird erstellt, danach werden
alle existierenden Einhängungen neu als \fBMS_SLAVE\fP 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 \fIMountFlags=\fP konfigurierten Forpflanzungsmodus eingehängt, siehe
unten\&.
.sp
Dateisystemnamensräume werden individuell für jeden mit »fork« vom
Diensteverwalter gestarteten Prozess eingerichtet\&. Einhängungen, die im
Namensraum des durch \fIExecStartPre=\fP erstellten Prozesses etabliert wurden
werden daher automatisch bereinigt, sobald der Prozess sich beendet und
werden für nachfolgend durch \fIExecStart=\fP mit Fork gestartete Prozesse
nicht verfügbar sein (und ähnliches gilt auch für die verschiedenen anderen
für Units konfigurierten Befehle)\&. Ähnlich erlaubt \fIJoinsNamespaceOf=\fP
nicht die gemeinsame Benutzung von Kernelnamensräumen zwischen Units, es
ermöglicht nur die gemeinsame Benutzung der Verzeichnisse /tmp/ und
/var/tmp/\&.
.sp
Andere Dateisystemnamensräume\-Einstellungen für Units \(em
\fIPrivateMounts=\fP, \fIPrivateTmp=\fP, \fIPrivateDevices=\fP, \fIProtectSystem=\fP,
\fIProtectHome=\fP, \fIReadOnlyPaths=\fP, \fIInaccessiblePaths=\fP,
\fIReadWritePaths=\fP, … \(em 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 werden\&.
.RE
.PP
\fIMountFlags=\fP
.RS 4
Akzeptiert eine Einhängeausbreitungseinstellung: \fBshared\fP, \fBslave\fP oder
\fBprivate\fP, 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 \fBmount\fP(2) für Details über Einhängeausbreitungen und
insbesondere die drei Ausbreitungsschalter\&.
.sp
Diese Einstellung steuert nur die \fIabschließenden\fP
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 \fIPrivateMounts=\fP 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 \fBslave\fP setzen\&. Setzen
der Option auf \fBshared\fP richtet die Ausbreitung in diesem Fall nicht wieder
ein\&.
.sp
Falls nicht gesetzt \(en aber es sind durch andere
Dateisystemnamensraumeinstellungen der Unit keine Dateisystemnamensräume
aktiviert \(en wird \fBshared\fP Einhängeausbreitung verwandt aber, wie
erwähnt, wird \fBslave\fP zuerst angewandt, Ausbreitung von den Prozessen der
Unit zum Hauptsystem bleibt weiterhin abgeschaltet\&.
.sp
Es wird nicht empfohlen, \fBprivate\fP 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\&.
.sp
Normalerweise ist es am besten, diese Einstellung unverändert zu lassen und
stattdessen abstraktere Dateisystemnamensraumoptionen zu verwenden,
insbesondere \fIPrivateMounts=\fP, siehe oben\&.
.RE
.SH SYSTEMAUFRUFFILTERUNG
.PP
\fISystemCallFilter=\fP
.RS 4
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 Beendiung mit dem Signal
\fBSIGSYS\fP führen, falls sie nicht aufgeführt sind (Freigabeliste)\&. Falls
das erste Zeichen der Liste »~« ist, wird die Wirkung invertiert: nur die
aufgeführten Systemaufrufe führen zu einer sofortigen Prozessbeendigung
(Verbotsliste)\&. Freigegebene Systemaufrufe und Systemaufrufgruppen kann
optional ein Doppelpunkt (»:«) und »errno«\-Fehlernummern (zwischen 0 und
4095) oder Fehlernummernamen wie \fBEPERM\fP, \fBEACCES\fP oder \fBEUCLEAN\fP
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 \fISystemCallErrorNumber=\fP angegebenen Vorrang\&. Falls
der Betrieb im Benutzermodus oder im Systemmodus aber ohne die Capability
\fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=nobody\fP) erfolgt, wird
\fINoNewPrivileges=yes\fP impliziert\&. Diese Funktionalittä 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 \fBexecve\fP, \fBexit\fP,
\fBexit_group\fP, \fBgetrlimit\fP, \fBrt_sigreturn\fP, \fBsigreturn\fP 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\&.
.sp
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
\fISystemCallArchitectures=native\fP oder ähnlichem zu kombinieren\&.
.sp
Beachten Sie, dass strenge Systemaufruffilterung die Ausführungs\- und
Fehlerbehandlungs\-Code\-Pfade des Diensteaufrufs beeinflussen
können\&. Insbesondere wird der Zugriff auf den Systemaufruf \fBexecve\fP für
die Ausführung des Diensteprogrammes benutzt \(em 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 Gruppen 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\&.
.sp
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 \fBread\fP und
\fBwrite\fP beginnen und direkt danach eine Ausschlussliste mit \fBwrite\fP
hinzufügen, dann wird \fBwrite\fP aus der Menge entfernt\&.)
.sp
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\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&3.\ \&Derzeit vordefinierte Systemaufrufgruppen\fP
.TS
allbox tab(:);
lB lB.
T{
Gruppe
T}:T{
Beschreibung
T}
.T&
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l
l l.
T{
@aio
T}:T{
Asynchrone E/A (\fBio_setup\fP(2), \fBio_submit\fP(2) und verwandte Aufrufe)
T}
T{
@basic\-io
T}:T{
Systemaufrufe für grundlegende E/A: Lesen, Schreiben, Suchen, Dateideskriptorenduplizieren und Schließen (\fBread\fP(2), \fBwrite\fP(2) und verwandte Aufrufe)
T}
T{
@chown
T}:T{
Änderung der Dateieigentümerschaft (\fBchown\fP(2), \fBfchownat\fP(2) und verwandte Aufrufe)
T}
T{
@clock
T}:T{
Systemaufrufe zur Änderung der Systemuhr (\fBadjtimex\fP(2), \fBsettimeofday\fP(2) und verwandte Aufrufe)
T}
T{
@cpu\-emulation
T}:T{
Systemaufrufe für CPU\-Emulierungsfunktionen (\fBvm86\fP(2) und verwandte Aufrufe)
T}
T{
@debug
T}:T{
Fehlersuche, Leistungsüberwachung und Nachverfolgungsfunktionen (\fBptrace\fP(2), \fBperf_event_open\fP(2) und verwandte Aufrufe)
T}
T{
@file\-system
T}:T{
Dateisystemaktionen: Öffnen, Dateien und Verzeichnisse zum Lesen und Schreiben erstellen, sie umbenennen oder entfernen, Lesen von Dateieigenschaften oder Erstellen von harten und symbolischen Links
T}
T{
@io\-event
T}:T{
Systemaufrufe für Ereignisschleifen (\fBpoll\fP(2), \fBselect\fP(2), \fBepoll\fP(7), \fBeventfd\fP(2) und verwandte Aufrufe)
T}
T{
@ipc
T}:T{
Pipes, SysV IPC, POSIX\-Nachrichtenwarteschlangen und andere IPC (\fBmq_overview\fP(7), \fBsvipc\fP(7))
T}
T{
@keyring
T}:T{
Kernel\-Schlüsselbundzugriff (\fBkeyctl\fP(2) und verwandte Aufrufe)
T}
T{
@memlock
T}:T{
Sperren von Speicher im RAM (\fBmlock\fP(2), \fBmlockall\fP(2) und verwandte Aufrufe)
T}
T{
@module
T}:T{
Laden und Entladen von Kernelmodulen (\fBinit_module\fP(2), \fBdelete_module\fP(2) und verwandte Aufrufe)
T}
T{
@mount
T}:T{
Einhängen und Aushängen von Dateisystemen (\fBmount\fP(2), \fBchroot\fP(2) und verwandte Aufrufe)
T}
T{
@network\-io
T}:T{
Socket\-E/A (einschließlich lokalem AF_UNIX): \fBsocket\fP(7), \fBunix\fP(7)
T}
T{
@obsolete
T}:T{
Ungewöhnliches, veraltetes oder nicht implementiertes (\fBcreate_module\fP(2), \fBgtty\fP(2), …)
T}
T{
@privileged
T}:T{
Alle Systemaufrufe, die Administrator\-Capabilities benötigen (\fBcapabilities\fP(7))
T}
T{
@process
T}:T{
Prozesssteuerung, \-ausführung, Namensraumaktionen  (\fBclone\fP(2), \fBkill\fP(2), \fBnamespaces\fP(7), …)
T}
T{
@raw\-io
T}:T{
Roher E/A\-Port\-Zugriff (\fBioperm\fP(2), \fBiopl\fP(2), \fBpciconfig_read()\fP, …)
T}
T{
@reboot
T}:T{
Systemaufrufe für den Neustart und die Neustartvorbereitung (\fBreboot\fP(2), \fBkexec()\fP, …)
T}
T{
@resources
T}:T{
Systemaufrufe für die Änderung von Ressourcenbeschränkungen, Speicher\- und Schedulingparametern (\fBsetrlimit\fP(2), \fBsetpriority\fP(2), …)
T}
T{
@setuid
T}:T{
Systemaufrufe zur Änderung der Benutzerkennung und Gruppenberechtigungen (\fBsetuid\fP(2), \fBsetgid\fP(2), \fBsetresuid\fP(2), …)
T}
T{
@signal
T}:T{
Systemaufrufe für die Veränderung und Handhabung von Prozesssignalen (\fBsignal\fP(2), \fBsigprocmask\fP(2), …)
T}
T{
@swap
T}:T{
Systemaufrufe für die Aktivierung/Deaktivierung von Auslagerungsgeräten (\fBswapon\fP(2), \fBswapoff\fP(2))
T}
T{
@sync
T}:T{
Synchronisierung von Dateien und Speicher auf Platte: (\fBfsync\fP(2), \fBmsync\fP(2) und verwandte Aufrufe)
T}
T{
@system\-service
T}:T{
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 überspezielle Schnittstellen ausschließt\&. Beispielsweise sind die folgenden APIs ausgeschlossen: »@clock«, »@mount«, »@swap«, »@reboot«\&.
T}
T{
@timer
T}:T{
Systemaufrufe für Scheduling\-Aktionen von Time (\fBalarm\fP(2), \fBtimer_create\fP(2), …)
T}
.TE
.sp 1
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 \fBsystemd\-analyze\ \&syscall\-filter\fP, um die tatsächliche Liste der Systemaufrufe in jedem
Filter aufzuführen\&.
.sp
Im allgemeinen ist das explizite Erlauben von Systemaufrufen (statt einer
Ausschlussliste) der sichere Betriebsmodus\&. Es wird empfohlen, für alle
langlaufenden Systemdienste eine Liste explizit erlaubter Systemaufrufe zu
erzwingen\&. Insbesondere sind die nachfolgenden Zeilen eine relativ sichere
grundlegende Wahl für den Großteil der Systemdienste:
.sp
.if  n \{\
.RS 4
.\}
.nf
[Service]
SystemCallFilter=@system\-service
SystemCallErrorNumber=EPERM
.fi
.if  n \{\
.RE
.\}
.sp
Es wird empfohlen, die Dateisystem\-Namensraum\-bezogenen Optionen mit
\fISystemCallFilter=~@mount\fP zu kombinieren, um zu verhindern, dass die
Prozesse der Unit die Abbildungen rückgängig machen\&. Insbesondere sind
dies die Optionen \fIPrivateTmp=\fP, \fIPrivateDevices=\fP, \fIProtectSystem=\fP,
\fIProtectHome=\fP, \fIProtectKernelTunables=\fP, \fIProtectControlGroups=\fP,
\fIReadOnlyPaths=\fP, \fIInaccessiblePaths=\fP und \fIReadWritePaths=\fP\&.
.RE
.PP
\fISystemCallErrorNumber=\fP
.RS 4
Akzeptiert eine »errno«\-Fehlernummer (zwischen 1 und 4095) oder einen
Errno\-Namen wie \fBEPERM\fP, \fBEACCES\fP oder \fBEUCLEAN\fP, der zurückgeliefert
werden soll, wenn der mit \fISystemCallFilter=\fP konfigurierte
Systemaufruffilter ausgelöst wird, statt den Prozess sofort zu
beenden\&. 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\&.
.RE
.PP
\fISystemCallArchitectures=\fP
.RS 4
Akzeptiert eine Leerzeichen\-getrennte Liste von Architekturkennungen, die in
den Systemaufrufilter eingeschlossen werden sollen\&. Die bekannten
Architekturkennungen sind die gleichen wie für das in \fBsystemd.unit\fP(5)
beschriebene \fIConditionArchitecture=\fP, sowie \fBx32\fP, \fBmips64\-n32\fP,
\fBmips64\-le\-n32\fP und die besondere Kennung \fBnative\fP\&. Die besondere
Kennung \fBnative\fP 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 \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von
\fIUser=\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&. Standardmäßig
wird diese Option auf die leere Liste gesetzt, d\&.h\&. keine
Systemaufrufarchitekturfilterung erfolgt\&.
.sp
Falls diese Einstellung verwandt wird, wird den Prozessen dieser Unit nur
der Aufruf nativer Systemaufrufe erlaubt und Systemaufrufe der festgelegten
Architektur\&. 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\&.
.sp
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 auf das native ABI des
Systems auferlegten Einschränkungen zu umgehen\&. Insbesondere ist das
Setzen von \fISystemCallArchitectures=native\fP für das Deaktivieren
nichtnativer ABIs eine gute Wahl\&.
.sp
Systemaufrufarchitekturen können auch systemweit mittels der Option
\fISystemCallArchitectures=\fP in der globalen Konfiguration eingeschränkt
werden\&. Siehe \fBsystemd\-system.conf\fP(5) für Details\&.
.RE
.SH UMGEBUNGSVARIABLEN
.PP
\fIEnvironment=\fP
.RS 4
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\&.
.sp
Beispiel:
.sp
.if  n \{\
.RS 4
.\}
.nf
Environment="VAR1=Wort1 Wort2" VAR2=Wort3 "VAR3=$Wort 5 6"
.fi
.if  n \{\
.RE
.\}
.sp
ergibt drei Variablen »VAR1«, »VAR2«, »VAR3« mit den Werten »Wort1 Wort2«,
»Wort3«, »$Wort 5 6«\&.
.sp
Siehe \fBenviron\fP(7) für Details über Umgebungsvariablen\&.
.sp
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\&.
.RE
.PP
\fIEnvironmentFile=\fP
.RS 4
Ähnlich zu \fIEnvironment=\fP, 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\&.
.sp
Das übergebene Argument sollte ein absoluter Dateiname oder ein
Platzhalterausdruck sein, dem optional »\-« vorangestellt werden kann, um
anzuzeigen, das sie nicht gelesen 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\&.
.sp
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)\&.
.sp
Einstellungen von diesen Dateien setzen mit \fIEnvironment=\fP 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\&.
.RE
.PP
\fIPassEnvironment=\fP
.RS 4
Ü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 übergebenen
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\&.
.sp
Variablen, die aufgrund dieser Einstellung für aufgerufene Prozesse gesetzt
werden, unterliegen der Möglichkeit, durch solche, die mit \fIEnvironment=\fP
oder \fIEnvironmentFile=\fP konfiguriert wurden, außer Kraft gesetzt zu
werden\&.
.sp
Beispiel:
.sp
.if  n \{\
.RS 4
.\}
.nf
PassEnvironment=VAR1 VAR2 VAR3
.fi
.if  n \{\
.RE
.\}
.sp
übergibt die drei Variablen »VAR1«, »VAR2«, »VAR3« mit den für diese
Variablen in PID1 gesetzten Werten\&.
.sp
Siehe \fBenviron\fP(7) für Details über Umgebungsvariablen\&.
.RE
.PP
\fIUnsetEnvironment=\fP
.RS 4
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:
ein 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 \fIUnsetEnvironment=\fP als abschließender Schritt
angewandt wird, wenn die an den auszuführenden Prozess zu übergebene
Umgebungsliste zusammengestellt wird\&. Das bedeutet, dass es Zuweisungen
von jeder Konfigurationsquelle rückgängig machen könnte, einschließlich
Zuweisungen, die mittels \fIEnvironment=\fP oder \fIEnvironmentFile=\fP erfolgten,
die von der globalen Menge der Umgebungsvariablen des Systemverwalters
geerbt wurden, die vom Diensteverwalter selbst gesetzt wurden (wie
\fI$NOTIFY_SOCKET\fP und ähnliche) oder die durch ein PAM\-Modul gesetzt wurden
(falls \fIPAMName=\fP benutzt wird)\&.
.sp
Siehe \fBenviron\fP(7) für Details über Umgebungsvariablen\&.
.RE
.SH "PROTOKOLLIERUNG UND SYSTEM\-EIN\-/\-AUSGABE"
.PP
\fIStandardInput=\fP
.RS 4
Steuert, wohin der Dateideskriptor 0 (STDIN) des ausgeführten Prozesses
verbunden ist\&. Akzeptiert \fBnull\fP, \fBtty\fP, \fBtty\-force\fP, \fBtty\-fail\fP,
\fBdata\fP, \fBfile:\fP\fIPfad\fP, \fBsocket\fP oder \fBfd:\fP\fIName\fP\&.
.sp
Falls \fBnull\fP ausgewählt wird, wird die Standardeingabe mit /dev/null
verbunden, d\&.h\&. alle Leseversuche durch den Prozess werden sofort zu
einem EOF führen\&.
.sp
Falls \fBtty\fP ausgewählt ist, wird die Standardeingabe mit einem TTY (wie mit
\fITTYPath=\fP konfiguriert ist, 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\&.
.sp
\fBtty\-force\fP ist ähnlich zu \fBtty\fP, 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\&.
.sp
\fBtty\-fail\fP ist ähnlich zu \fBtty\fP, falls aber das Terminal bereits einen
steuernden Prozess hat, schlägt das Hochfahren des ausgeführten Prozesses
fehl\&.
.sp
Die Option \fBdata\fP kann zur Konfiguration beliebiger textueller oder binärer
Daten, die mittels Standardeingabe an den ausgeführten Prozess übergeben
werden sollen, verwandt werden\&. Die zu übergebenen Daten werden mittels
\fIStandardInputText=\fP/\fIStandardInputData=\fP (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\&.
.sp
Die Option \fBfile:\fP\fIPfad\fP 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 besondere Datei beziehen kann\&. Falls ein \fBAF_UNIX\fP\-Socket
in dem Dateisystem festgelegt ist, wird mit ihm ein Strom\-Socket
verbunden\&. Letzteres ist nützlich, um die Standardeingabe eines beliebigen
Prozesses mit einem beliebigen Systemdienst zu verbinden\&.
.sp
Die Option »\fBsocket\fP« ist nur in Socket\-aktivierten Diensten gültig und es
muss in der relevanten Socket\-Unit\-Datei (siehe \fBsystemd.socket\fP(5) für
Details) \fIAccept=yes\fP 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 \fBinetd\fP(8)\-Socket\-Daemon\-Aktivierung
entwickelt wurden\&.
.sp
Die Option \fBfd:\fP\fIName\fP 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 \fISockets=\fP 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 \fIFileDescriptorName=\fP in \fBsystemd.socket\fP(5) für weitere
Details über benannte Dateideskriptoren und ihrer Sortierung\&.
.sp
Diese Einstellung ist standardmäßig \fBnull\fP\&.
.sp
Beachten Sie, dass Dienste, die \fBDefaultDependencies=no\fP festlegen und
\fIStandardInput=\fP oder \fIStandardOutput=\fP mit
\fBtty\fP/\fBtty\-force\fP/\fBtty\-fail\fP verwenden,
\fBAfter=systemd\-vconsole\-setup\&.service\fP festlegen sollten, um
sicherzustellen, dass die TTY\-Initialisierung abgeschlossen ist, bevor sie
starten\&.
.RE
.PP
\fIStandardOutput=\fP
.RS 4
Steuert, wohin der Dateideskriptor 1 (STDOUT) des ausgeführten Prozesses
verbunden ist\&. Akzeptiert entweder \fBinherit\fP, \fBnull\fP, \fBtty\fP,
\fBjournal\fP, \fBsyslog\fP, \fBkmsg\fP, \fBjournal+console\fP, \fBsyslog+console\fP,
\fBkmsg+console\fP, \fBfile:\fP\fIPfad\fP, \fBappend:\fP\fIPfad\fP, \fBsocket\fP oder
\fBfd:\fP\fIName\fP\&.
.sp
\fBinherit\fP dupliziert den Dateideskriptor der Standardeingabe für die
Standardausgabe\&.
.sp
\fBnull\fP verbindet die Standardausgabe mit /dev/null, d\&.h\&. alles dahin
geschriebene geht verloren\&.
.sp
\fBtty\fP verbindet die Standardausgabe mit einem TTY (wie in \fITTYPath=\fP
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\&.
.sp
\fBjournal\fP verbindet die Standardausgabe mit dem Journal, das über
\fBjournalctl\fP(1) erreichbar ist\&. Beachten Sie, dass alles, was nach Syslog
oder Kmsg (siehe unten) geschrieben wird, implizit auch im Journal
gespeichert wird, die zwei speziellen unten aufgeführten Optionen sind daher
eine Obermenge dieser Option\&.
.sp
\fBsyslog\fP verbindet die Standardausgabe mit dem Systemprotokollierdienst
\fBsyslog\fP(3), zusätzlich zum Journal\&. Beachten Sie, dass der
Journal\-Daemon normalerweise so konfiguriert ist, dass er alles, was er
empfängt, sowieso zum Syslog weiterleitet, wodurch diese Option in diesem
Fall keinen Unterschied zu \fBjournal\fP darstellt\&.
.sp
\fBkmsg\fP verbindet die Standardeingabe mit dem Kernelprotkollpuffer, der über
\fBdmesg\fP(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 \fBjournal\fP
darstellt\&.
.sp
\fBjournal+console\fP, \fBsyslog+console\fP und \fBkmsg+console\fP arbeiten auf eine
ähnliche Art wie die drei Optionen oben, kopieren aber auch sämtliche
Ausgabe auf die Systemkonsole\&.
.sp
Die Option \fBfile:\fP\fIPfad\fP kann zum Verbinden eines bestimmten
Dateisystemobjektes mit der Standardausgabe verwandt werden\&. Die Semantik
ist ählich der identischen, oben dargestellten Option
\fIStandardInput=\fP\&. Falls sich \fIPfad\fP 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 \fBAF_UNIX\fP\-Socket im Dateisystem bezieht, da in
diesem Fall nur eine einzelne Stromverbindung für sowohl Ein\- als auch
Ausgabe erstellt wird\&.
.sp
\fBappend:\fP\fIPfad\fP ist ähnlich zu \fBfile:\fP\fIpath\fP oben, es öffnet die Datei
aber im Anhängemodus\&.
.sp
\fBsocket\fP verbindet die Standardausgabe zu einem mittels Socket\-Aktivierung
erlangten Socket\&. Die Semantik ist ähnlich der identischen, oben
dargestellten Option \fIStandardInput=\fP\&.
.sp
Die Option \fBfd:\fP\fIName\fP 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 \fISockets=\fP 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 \fIFileDescriptorName=\fP in \fBsystemd.socket\fP(5) für weitere
Details über benannte Dateideskriptoren und ihrer Sortierung\&.
.sp
Falls die Standardausgabe (oder die Fehlerausgabe, siehe unten) einer Unit
mit dem Journal, dem Syslog oder dem Kernelprotokollpuffer verbunden ist,
wird die Unit implizit eine Abhängigkeit vom Typ \fIAfter=\fP 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 \fBAF_UNIX\fP\-Strom\-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 »\fBecho "hello" >
/dev/stderr\fP« zum Schreiben von Text nach Stderr nicht funktionieren
wird\&. Um dies zu entschärfen, verwenden Sie stattdessen die Konstruktion
»\fBecho "hello" >&2\fP«, die größtenteils äquivalent ist und diesen
Fallstrick vermeidet\&.
.sp
Der Vorgabewert dieser Einstellung ist der mit \fIDefaultStandardOutput=\fP in
\fBsystemd\-system.conf\fP(5) gesetzte Wert, der standardmäßig \fBjournal\fP
ist\&. Beachten Sie, dass dieser Parameter zum Hinzufügen zusätzlicher
Abhängigkeiten führen kann (siehe oben)\&.
.RE
.PP
\fIStandardError=\fP
.RS 4
Steuert, wohin Dateideskriptor 2 (STDERR) des ausgeführten Prozesses
verbunden ist\&. Die verfügbaren Optionen sind identisch zu denen von
\fIStandardOutput=\fP mit einigen Ausnahmen: falls auf \fBinherit\fP gesetzt, wird
der für die Standardausgabe verwandte Dateideskriptor für den Standardfehler
dupliziert, während \fBfd:\fP\fIName\fP den Vorgabedateideskriptorname von
»stderr« verwenden wird\&.
.sp
Der Vorgabewert dieser Einstellung ist der mit \fIDefaultStandardError=\fP in
\fBsystemd\-system.conf\fP(5) gesetzte Wert, der standardmäßig \fBinherit\fP
ist\&. Beachten Sie, dass dieser Parameter zum Hinzufügen zusätzlicher
Abhängigkeiten führen kann (siehe oben)\&.
.RE
.PP
\fIStandardInputText=\fP, \fIStandardInputData=\fP
.RS 4
Konfiguriert beliebige textuelle oder binärer Daten, die mittels
Dateideskriptor 0 (STDIN) an den ausgeführten Prozess übergeben werden
sollen\&. Diese Einstellung hat keine Wirkung, außer \fIStandardInput=\fP ist
auf \fBdata\fP gesetzt\&. Verwenden Sie diese Option, um Prozesseingabedaten
direkt in die Unit\-Datei einzubetten\&.
.sp
\fIStandardInputText=\fP 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 »\en« an das Ende oder den Anfang
einer Zeile eingefügt werden, um eine leere Zeile einzufügen)\&.
.sp
\fIStandardInputData=\fP akzeptiert beliebige, in
\m[blue]\fBBase64\fP\m[]\&\s-2\u[4]\d\s+2 kodierte binäre Daten\&. Es werden
keine Maskiersequenzen oder Kennzeichner aufgelöst\&. Sämtliche
Leeraumzeichen in der kodierten Version werden während der Dekodierung
ignoriert\&.
.sp
Beachten Sie, dass \fIStandardInputText=\fP und \fIStandardInputData=\fP 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\&.
.sp
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 »\e« vorangestellt (siehe
\fBsystemd.unit\fP(5) für Details)\&. Dies ist insbesondere für große Daten,
die mit diesen Optionen konfiguriert werden, nützlich\&. Beispiel:
.sp
.if  n \{\
.RS 4
.\}
.nf
…
StandardInput=data
StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl \e
                  LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \e
                  dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug \e
                  enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \e
                  SWNrZSEK
…
.fi
.if  n \{\
.RE
.\}
.RE
.PP
\fILogLevelMax=\fP
.RS 4
Konfiguriert eine Filterung gemäß Protokollierstufe der durch diese Unit
erstellten Protokollnachrichten\&. Akzeptiert eine \fBsyslog\fP\-Protokollstufe,
entweder \fBemerg\fP (niedrigste Protokollierstufe, nur Nachrichten höchster
Priorität), \fBalert\fP, \fBcrit\fP, \fBerr\fP, \fBwarning\fP, \fBnotice\fP, \fBinfo\fP oder
\fBdebug\fP (höchste Protokollierstufe, auch Nachrichten niedrigster
Priorität)\&. Siehe \fBsyslog\fP(3) für Details\&. Standardmäßig wird keine
Filterung angewandt (d\&.h\&. die maximale Protokollierstufe ist
standardmäßig \fBdebug\fP)\&. Verwenden Sie diese Option, um das
Protokolliersystem zu konfigurieren, damit es Protokollnachrichten eines
bestimmten Dienstes oberhalb der festgelegten Stufe verwirft\&. Setzen Sie
beispielsweise \fILogLevelMax=\fP\fBinfo\fP, 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 \fBjournald.conf\fP(5) konfiguriertes
\fIMaxLevelStore=\fP verbieten, Nachrichten von höheren Protokollierstufen auf
Platte zu speichen, selbst wenn das Unit\-bezogene \fILogLevelMax=\fP die
Verarbeitung erlaubte\&.
.RE
.PP
\fILogExtraFields=\fP
.RS 4
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 \fBsystemd.journal\-fields\fP(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\&.
.RE
.PP
\fILogRateLimitIntervalSec=\fP, \fILogRateLimitBurst=\fP
.RS 4
Konfiguriert die Ratenbegrenzung, die auf von dieser Unit erstellten
Nachrichten angewandt wird\&. Falls in dem durch \fILogRateLimitIntervalSec=\fP
definierten Intervall mehr als in \fILogRateLimitBurst=\fP festgelegte
Nachrichten durch den Dienst protokolliert werden, werden alle weiteren
Nachrichten in dem Intervall verworfen, bis das Intervall vorüber ist\&. Es
wird eine Nachricht über die verworfenen Nachrichten erstellt\&. Die
Zeitspezifikation für \fILogRateLimitIntervalSec=\fP kann in einer der
folgenden Einheiten erfolgen: »s«, »min«, »h«, »ms«, »us« (siehe
\fBsystemd.time\fP(7) für Details)\&. Die Voreinstellungen erfolgen durch die
in \fBjournald.conf\fP(5) konfigurierten \fIRateLimitIntervalSec=\fP und
\fIRateLimitBurst=\fP\&.
.RE
.PP
\fISyslogIdentifier=\fP
.RS 4
Setzt den Prozessnamen (»\fBsyslog\fP\-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 \fIStandardOutput=\fP oder \fIStandardError=\fP auf \fBjournal\fP, \fBsyslog\fP
oder \fBkmsg\fP gesetzt ist (oder die gleichen Einstellungen in Kombination mit
\fB+console\fP)\&. Sie wird nur auf Protokollnachrichten, die nach Stdout oder
Stderr geschrieben werden, angewandt\&.
.RE
.PP
\fISyslogFacility=\fP
.RS 4
Setzt den \fBsyslog\fP\-Einrichtungskennzeichner, der beim Protokollieren
verwandt werden soll\&. Entweder \fBkern\fP, \fBuser\fP, \fBmail\fP, \fBdaemon\fP,
\fBauth\fP, \fBsyslog\fP, \fBlpr\fP, \fBnews\fP, \fBuucp\fP, \fBcron\fP, \fBauthpriv\fP, \fBftp\fP,
\fBlocal0\fP, \fBlocal1\fP, \fBlocal2\fP, \fBlocal3\fP, \fBlocal4\fP, \fBlocal5\fP, \fBlocal6\fP
oder \fBlocal7\fP\&. Siehe \fBsyslog\fP(3) für Details\&. Diese Option ist nur
nützlich, wenn \fIStandardOutput=\fP oder \fIStandardError=\fP auf \fBjournal\fP,
\fBsyslog\fP oder \fBkmsg\fP gesetzt ist (oder die gleichen Einstellungen in
Kombination mit \fB+console\fP)\&. Sie wird nur auf Protokollnachrichten, die
nach Stdout oder Stderr geschrieben werden, angewandt\&. Standardmäßig
\fBdaemon\fP\&.
.RE
.PP
\fISyslogLevel=\fP
.RS 4
Die Vorgabe\-\fBsyslog\fP\-Protokollierstufe, die beim Protokollieren zum
Protokollierungssystem oder Kernelprotokollpuffer verwandt werden
soll\&. Entweder \fBemerg\fP, \fBalert\fP, \fBcrit\fP, \fBerr\fP, \fBwarning\fP, \fBnotice\fP,
\fBinfo\fP oder \fBdebug\fP\&. Siehe \fBsyslog\fP(3) für Details\&. Diese Option ist
nur nützlich, wenn \fIStandardOutput=\fP oder \fIStandardError=\fP auf \fBjournal\fP,
\fBsyslog\fP oder \fBkmsg\fP gesetzt ist (oder die gleichen Einstellungen in
Kombination mit \fB+console\fP)\&. 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 hier festgelegte Vorgabeprotokollstufe außer Kraft zu
setzen\&. Die Auswertung dieser vorangestellten Werte kann mit
\fISyslogLevelPrefix=\fP deaktiviert werden, siehe unten\&. Für Details siehe
\fBsd\-daemon\fP(3)\&. Standardmäßig \fBinfo\fP\&.
.RE
.PP
\fISyslogLevelPrefix=\fP
.RS 4
Akzeptiert ein logisches Argument\&. Falls wahr und \fIStandardOutput=\fP oder
\fIStandardError=\fP auf \fBjournal\fP, \fBsyslog\fP oder \fBkmsg\fP gesetzt ist (oder
die gleichen Einstellungen in Kombination mit \fB+console\fP), 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 \fBsd\-daemon\fP(3)\&. Standardmäßig
wahr\&.
.RE
.PP
\fITTYPath=\fP
.RS 4
Setzt den zu verwendenden Terminalgeräteknoten, falls die Standardeingabe,
\-ausgabe oder der Standardfehler mit einem TTY verbunden ist (siehe
oben)\&. Standardmäßig /dev/console\&.
.RE
.PP
\fITTYReset=\fP
.RS 4
Setzt das mit \fITTYPath=\fP festgelegte Terminalgerät vor und nach der
Ausführung zurück\&. Standardmäßig »no«\&.
.RE
.PP
\fITTYVHangup=\fP
.RS 4
Trennt alle Clients, die das mit \fITTYPath=\fP festgelegte Terminalgerät vor
und nach der Ausführung geöffnet haben\&. Standardmäßig »no«\&.
.RE
.PP
\fITTYVTDisallocate=\fP
.RS 4
If the terminal device specified with \fITTYPath=\fP 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"\&.
.RE
.SH "SYSTEM V\-KOMPATIBILITÄT"
.PP
\fIUtmpIdentifier=\fP
.RS 4
Akzeptiert eine Kennzeichnungszeichenkette aus vier Zeichen für einen
\fButmp\fP(5)\- und Wtmp\-Eintrag für diesen Dienst\&. Dies sollte nur für
Dienste wie \fBgetty\fP\-Implementierungen (wie \fBagetty\fP(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 \fBgetty\fP\-Prozess ausgeführt würden (siehe
unten)\&. Falls die Konfigurationszeichenkette länger als vier Zeichen ist,
wird sie abgeschnitten und die vier Zeichen am Ende werden verwandt\&. Diese
Einstellung interpretiert %I\-artige Zeichenkettenersetzungen\&. Diese
Einstellung ist standardmäßig nicht gesetzt, d\&.h\&. keine
Utmp\-/Wtmp\-Einträge werden für diesen Dienst erstellt oder bereinigt\&.
.RE
.PP
\fIUtmpMode=\fP
.RS 4
Akzeptiert entweder »init«, »login« oder »user«\&. Falls \fIUtmpIdentifier=\fP
gesetzt ist, steuert dies die Art der für diesen Dienst erstellten
\fButmp\fP(5)/wtmp\-Einträge\&. Diese Einstellung ist wirkungslos, außer
\fIUtmpIdentifier=\fP ist auch gesetzt\&. Falls »init« gesetzt ist, wird nur
ein \fBINIT_PROCESS\fP\-Eintrag erstellt und der aufgerufene Prozess muss eine
\fBgetty\fP\-kompatible Utmp/Wtmp\-Logik implementieren\&. Falls »login« gesetzt
ist, wird zuerst ein \fBINIT_PROCESS\fP\-Eintrag, gefolgt von einem
\fBLOGIN_PROCESS\fP\-Eintrag erstellt\&. In diesem Fall muss der aufgerufene
Prozess eine \fBlogin\fP(1)\-kompatible Utmp/Wtmp\-Logik implementieren\&. Falls
»user« festgelegt ist, wird zuerst ein \fBINIT_PROCESS\fP\-Eintrag, dann ein
\fBLOGIN_PROCESS\fP\-Eintrag und schließlich ein \fBUSER_PROCESS\fP\-Eintrag
erstellt\&. In diesem Fall kann der Prozess jeder Prozess sein, der zum
Betrieb als Sitzungsleiter geeignet ist\&. Standardmäßig »init«\&.
.RE
.SH "UMGEBUNGSVARIABLEN IN ERZEUGTEN PROZESSEN"
.PP
Durch den Diensterwalter 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 \fIPassEnvironment=\fP
geändert werden), aber Prozesse, die durch Benutzerdiensteverwalterinstanzen
gestartet werden, erben im Allgemein alle für den Diensteverwalter selbst
gsetzten Umgebungsvariablen\&.
.PP
Für jeden aufgerufenen Prozess wird die Liste der gesetzten
Umgebungsvariablen aus den folgenden Quellen zusammengestellt:
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Variablen, die global für den Diensteverwalter mittels der Einstellung
\fIDefaultEnvironment=\fP in \fBsystemd\-system.conf\fP(5), der
Kernelbefehlszeilenoption \fIsystemd\&.setenv=\fP (siehe \fBsystemd\fP(1)) oder
mittels \fBsystemctl set\-environment\fP (siehe \fBsystemctl\fP(1)) konfiguriert
sind\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Durch den Diensteverwalter selbst definierte Variablen (siehe nachfolgende
Liste)
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Variablen, die durch den Umgebungsvariablenblock des Diensteverwalters
selbst gesetzt sind (abhängig von \fIPassEnvironment=\fP für den
Systemdiensteverwalter)
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Mittels \fIEnvironment=\fP in der Unit\-Datei gesetzte Variablen
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Aus mit \fIEnvironmentFile=\fP in der Unit\-Datei festgelegten Dateien gelesene
Variablen
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Falls \fIPAMName=\fP wirksam ist, siehe \fBpam_env\fP(8), durch alle PAM\-Module
gesetzte Variablen
.RE
.PP
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
\fIUnsetEnvironment=\fP aufgeführten Variablen wieder von der
zusammengestellten Variablenliste entfernt werden, direkt bevor sie an den
ausgeführten Prozess übergeben wird\&.
.PP
Die folgenden ausgewählten Umgebungsvariablen werden für jeden durch den
Diensteverwalter aufgerufenen Prozesse gesetzt oder fortgepflanzt:
.PP
\fI$PATH\fP
.RS 4
Durch Doppelpunkt getrennte Liste von Verzeichnissen, die beim Starten von
Programmen genutzt werden sollen\&. Systemd verwendet einen festgelegten
Wert: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin\&.
.RE
.PP
\fI$LANG\fP
.RS 4
Locale\&. Kann in \fBlocale.conf\fP(5) oder auf der Kernelbefehlszeile gesetzt
werden (siehe \fBsystemd\fP(1) und \fBkernel\-command\-line\fP(7))\&.
.RE
.PP
\fI$USER\fP, \fI$LOGNAME\fP, \fI$HOME\fP, \fI$SHELL\fP
.RS 4
Benutzername (zweifach), Home\-Verzeichnis und die Anmelde\-Shell\&. Die
Variablen sind für die Units, die \fIUser=\fP gesetzt haben, gesetzt, dazu
gehören Benutzer\-\fBsystemd\fP\-Instanzen\&. Siehe \fBpasswd\fP(5)\&.
.RE
.PP
\fI$INVOCATION_ID\fP
.RS 4
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\&.
.RE
.PP
\fI$XDG_RUNTIME_DIR\fP
.RS 4
Das Verzeichnis, das für Laufzeitobjekte (wie IPC\-Objekte) und flüchtige
Zustände verwandt werden soll\&. Wird für alle von der
Benutzer\-\fBsystemd\fP\-Instanz ausgeführten Prozesse sowie von allen
Systemdiensten, die \fIPAMName=\fP mit einem PAM\-Stack, der \fBpam_systemd\fP
enthält, verwandt wird, gesetzt\&. Siehe unten und \fBpam_systemd\fP(8) für
weitere Informationen\&.
.RE
.PP
\fI$MAINPID\fP
.RS 4
Die PID des Hauptprozesses der Unit, falls bekannt\&. Dies wird nur für
durch \fIExecReload=\fP und ähnliches aufgerufene Steuerprozesse gesetzt\&.
.RE
.PP
\fI$MANAGERPID\fP
.RS 4
Die PID der Benutzer\-\fBsystemd\fP\-Instanz, gesetzt für davon erzeugte
Prozesse\&.
.RE
.PP
\fI$LISTEN_FDS\fP, \fI$LISTEN_PID\fP, \fI$LISTEN_FDNAMES\fP
.RS 4
Informationen über Dateideskriptoren, die an einen Dienst für
Socket\-Aktivierung weitergegeben wurden\&. Siehe \fBsd_listen_fds\fP(3)\&.
.RE
.PP
\fI$NOTIFY_SOCKET\fP
.RS 4
Das Socket, mit dem \fBsd_notify()\fP kommuniziert\&. Siehe \fBsd_notify\fP(3)\&.
.RE
.PP
\fI$WATCHDOG_PID\fP, \fI$WATCHDOG_USEC\fP
.RS 4
Informationen über Watchdog\-Aufrechterhaltungsbenachrichtigungen\&. Siehe
\fBsd_watchdog_enabled\fP(3)\&.
.RE
.PP
\fI$TERM\fP
.RS 4
Terminaltyp, nur für mit einem Terminal verbundene Units gesetzt
(\fIStandardInput=tty\fP, \fIStandardOutput=tty\fP oder
\fIStandardError=tty\fP)\&. Siehe \fBtermcap\fP(5)\&.
.RE
.PP
\fI$JOURNAL_STREAM\fP
.RS 4
Falls die Standardausgabe oder Standardfehlerausgabe des ausgeführten
Prozesses mit dem Journal verbunden ist (beispielsweise durch Setzen von
\fIStandardError=journal\fP) enthält \fI$JOURNAL_STREAM\fP das Gerät und die
Inodnummer des verbindenden Dateideskriptors, dezimal formatiert, getrennt
durch einen Doppelpunkt (»:«)\&. Dies erluabt 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 immernoch mit dem
Journal verbunden ist\&. Beachten Sie, dass es im allgemeinen nicht
ausreicht, zu prüfen, ob \fI$JOURNAL_STREAM\fP überhaupt gesetzt ist, da
Dienste externe Prozesse aufrufen könnten, die ihre Standardausgabe oder
Fehlerausgabe ersetzen könnten, ohne dabei die Umgebungsvariable
zurückzusetzen\&.
.sp
Falls sowohl die Standardausgabe als auch der Standardfehler des
ausgeführten Prozesses mit dem Journal über ein Strom\-Socket verbunden sind,
wird diese Umgebungsvariable Informationen über den Standardfehlerstrom
enthalten, da dies normalerweise das bevorzugte Ziel für Protokolldaten
ist\&. (Beachten Sie, dass typischerweise der gleiche Strom sowohl für die
Standardausgabe als auch den Standardfehler verwandt wird und daher die
Umgebungsvariable sehr wahrscheinlich Geräte\- und Inodeinformationen
enthalten wird, die auf beide Stromdateideskriptoren passt\&.)
.sp
Diese Umgebungsvariable ist hauptsächlich nützlich, um Diensten zu erlauben,
ihr verwandtes Protokollierungsprotokoll optional (mittels
\fBsd_journal_print\fP(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\&.
.RE
.PP
\fI$SERVICE_RESULT\fP
.RS 4
Diese Variable, die nur für den Dienste\-Unit\-Typ definiert ist, wird an alle
\fIExecStop=\fP\- und \fIExecStopPost=\fP\-Prozesse weitergegeben und kodiert das
»Ergebnis« des Prozesses\&. Derzeit sind die folgenden Werte definiert:
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&4.\ \&Definierte \fP\fI$SERVICE_RESULT\fP\-Werte
.TS
allbox tab(:);
lB lB.
T{
Wert
T}:T{
Bedeutung
T}
.T&
l l
l l
l l
l l
l l
l l
l l
l l
l l.
T{
"Erfolg"
T}:T{
Der Dienst lief erfolgreich und beendete sich sauber\&.
T}
T{
"protocol"
T}:T{
Das Protokoll wurde verletzt: der Dienst hat nicht die von seiner Unit\-Konfiguration verlangten Schritte absolviert (insbesondere was in der Einstellung \fIType=\fP konfiguriert wurde)\&.
T}
T{
"timeout"
T}:T{
Eine der Schritte hat die Zeit überschritten\&.
T}
T{
"exit\-code"
T}:T{
Diensteprozess hat sich mit einen von Null verschiedenen Exit\-Code beendet; siehe \fI$EXIT_CODE\fP unten für den tatsächlich zurückgelieferten Exit\-Code\&.
T}
T{
"signal"
T}:T{
Ein Diensteprozess wurde durch ein Signal regelwidrig beendet; ohne einen Speicherauszug\&. Siehe \fI$EXIT_CODE\fP unten für das tatsächliche Signal, das die Beendigung auslöste\&.
T}
T{
"core\-dump"
T}:T{
Ein Diensteprozess wurde durch ein Signal regelwidrig beendet und hat einen Speicherauszug ausgegeben\&. Siehe \fI$EXIT_CODE\fP unden für das Signal, das die Beendigung auslöste\&.
T}
T{
"watchdog"
T}:T{
Der Totemannschalter des Watchdogs war für diesen Dienst aktiviert, aber die Frist wurde verpasst\&.
T}
T{
"start\-limit\-hit"
T}:T{
Für die Unit war eine Startbegrenzung definiert und erreicht, wodurch der Start der Unit fehlschlug\&. Siehe \fIStartLimitIntervalSec=\fP und \fIStartLimitBurst=\fP von \fBsystemd.unit\fP(5) für Details\&.
T}
T{
"resources"
T}:T{
Eine Auffangbedingung, falls eine Systemaktion fehlschlug\&.
T}
.TE
.sp 1
Diese Umgebungsvariable ist nützlich, um den Fehlschlag oder die
erfolgreiche Beendigung eines Dienstes zu überwachen\&. Obowohl diese
Variable sowohl in \fIExecStop=\fP und \fIExecStopPost=\fP 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\&.
.RE
.PP
\fI$EXIT_CODE\fP, \fI$EXIT_STATUS\fP
.RS 4
Diese Umgebungsvariablen, die nur für den Dienste\-Unit\-Typ definiert sind,
werden an alle Prozesse aus \fIExecStop=\fP und \fIExecStopPost=\fP übergeben und
enthalten Exit\-Status/Code\-Informationen über den Hauptprozess des
Dienstes\&. Für die genaue Definitionen des Exit\-Codes und \-Status, siehe
\fBwait\fP(2)\&. \fI$EXIT_CODE\fP ist entweder »exited«, »killed« oder
»dumped«\&. \fI$EXIT_STATUS\fP enthält den als Zeichenkette formatierten
numerischen Exit\-Code falls \fI$EXIT_CODE\fP »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\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&5.\ \&Zusammenfassung der möglichen Variablenwerte für
Diensteergebnisse\fP
.TS
allbox tab(:);
lB lB lB.
T{
\fI$SERVICE_RESULT\fP
T}:T{
\fI$EXIT_CODE\fP
T}:T{
\fI$EXIT_STATUS\fP
T}
.T&
lt lt l
lt lt l
^ l l
lt lt l
^ lt l
lt lt l
lt lt l
lt lt l
lt l l
^ l l
^ l l
l l l
l l l
l s s.
T{
"Erfolg"
T}:T{
"exited"
T}:T{
"0"
T}
T{
"protocol"
T}:T{
not set
T}:T{
not set
T}
:T{
"exited"
T}:T{
"0"
T}
T{
"timeout"
T}:T{
"killed"
T}:T{
»TERM«, »KILL«
T}
:T{
"exited"
T}:T{
»0«, »1«, »2«, »3«, … »255«
T}
T{
"exit\-code"
T}:T{
"exited"
T}:T{
»1«, »2«, »3«, …, »255«
T}
T{
"signal"
T}:T{
"killed"
T}:T{
»HUP«, »INT«, »KILL«, …
T}
T{
"core\-dump"
T}:T{
"dumped"
T}:T{
»ABRT«, »SEGV«, »QUIT«, …
T}
T{
"watchdog"
T}:T{
"dumped"
T}:T{
"ABRT"
T}
:T{
"killed"
T}:T{
»TERM«, »KILL«
T}
:T{
"exited"
T}:T{
»0«, »1«, »2«, »3«, … »255«
T}
T{
"start\-limit\-hit"
T}:T{
not set
T}:T{
not set
T}
T{
"resources"
T}:T{
jeder der obigen
T}:T{
jeder der obigen
T}
T{
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 \fISuccessExitStatus=\fP zusätzliche Exit\-Stati erklärt werden, um die saubere Beendigung anzuzeigen, was in der Tabelle nicht wiedergegeben wird\&.
T}
.TE
.sp 1
.RE
.PP
Für Systemdienste können zusätzliche, durch Systemd definierte
Umgebungsvariablen für Dienste gesetzt werden, wenn \fIPAMName=\fP aktiviert
und \fBpam_systemd\fP Teil des ausgewählten PAM\-Stacks ist\&. Dies sind
insbesondere \fI$XDG_SEAT\fP und \fI$XDG_VTNR\fP, siehe \fBpam_systemd\fP(8) für
Details\&.
.SH PROZESS\-EXIT\-CODES
.PP
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 \fBfork\fP(2) erstellt
wurde, aber bevor der zugehörige Systemaufruf \fBexecve\fP(2) aufgerufen
wurde\&.) Insbesondere werden die durch die C\-Bibliothek, die
LSB\-Spezifikation und durch den Systemd\-Diensteverwalter selbst definierten
Exit\-Codes verwandt\&.
.PP
Die folgenden grundlegenden Dienste\-Exit\-Codes sind durch die C\-Bibliothek
definiert\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&6.\ \&Grundlegende Exit\-Codes der C\-Bibliothek\fP
.TS
allbox tab(:);
lB lB lB.
T{
Exit\-Code
T}:T{
Symbolischer Name
T}:T{
Beschreibung
T}
.T&
l l l
l l l.
T{
0
T}:T{
\fBEXIT_SUCCESS\fP
T}:T{
Generischer Erfolgs\-Code\&.
T}
T{
1
T}:T{
\fBEXIT_FAILURE\fP
T}:T{
Generischer Fehlschlag oder unspezifizierter Fehler\&.
T}
.TE
.sp 1
.PP
Die folgenden Dienste\-Exit\-Codes sind durch die
\m[blue]\fBLSB\-Spezifikation\fP\m[]\&\s-2\u[5]\d\s+2 festgelegt\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&7.\ \&LSB\-Dienste\-Exit\-Codes\fP
.TS
allbox tab(:);
lB lB lB.
T{
Exit\-Code
T}:T{
Symbolischer Name
T}:T{
Beschreibung
T}
.T&
l l l
l l l
l l l
l l l
l l l
l l l.
T{
2
T}:T{
\fBEXIT_INVALIDARGUMENT\fP
T}:T{
Ungültige oder überzählige Argumente\&.
T}
T{
3
T}:T{
\fBEXIT_NOTIMPLEMENTED\fP
T}:T{
Nicht implementierte Funktionalität\&.
T}
T{
4
T}:T{
\fBEXIT_NOPERMISSION\fP
T}:T{
Der Benutzer hat nicht genug Privilegien\&.
T}
T{
5
T}:T{
\fBEXIT_NOTINSTALLED\fP
T}:T{
Das Programm ist nicht installiert\&.
T}
T{
6
T}:T{
\fBEXIT_NOTCONFIGURED\fP
T}:T{
Das Programm ist nicht konfiguriert\&.
T}
T{
7
T}:T{
\fBEXIT_NOTRUNNING\fP
T}:T{
Das Programm läuft nicht\&.
T}
.TE
.sp 1
.PP
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\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&8.\ \&Systemd\-spezifische Exit\-Codes\fP
.TS
allbox tab(:);
lB lB lB.
T{
Exit\-Code
T}:T{
Symbolischer Name
T}:T{
Beschreibung
T}
.T&
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l.
T{
200
T}:T{
\fBEXIT_CHDIR\fP
T}:T{
Änderung des angeforderten Arbeitsverzeichnisses schlug fehl\&. Siehe \fIWorkingDirectory=\fP oben\&.
T}
T{
201
T}:T{
\fBEXIT_NICE\fP
T}:T{
Scheduling\-Priorität (Nice\-Stufe) konnte nicht gesetzt werden\&. Siehe \fINice=\fP oben\&.
T}
T{
202
T}:T{
\fBEXIT_FDS\fP
T}:T{
Ungewünschter Dateideskriptor konnte nicht geschlossen werden oder übergebene Dateideskriptoren konnten nicht angepasst werden\&.
T}
T{
203
T}:T{
\fBEXIT_EXEC\fP
T}:T{
Die tatsächliche Ausführung des Prozesses schlug fehl (genauer, der Systemaufruf \fBexecve\fP(2))\&. Höchstwahrscheinlich wird dies durch ein fehlendes oder nicht zugreifbares Programm hervorgerufen\&.
T}
T{
204
T}:T{
\fBEXIT_MEMORY\fP
T}:T{
Aufgrund von Speicherknappheit konnte eine Aktion nicht durchgeführt werden\&.
T}
T{
205
T}:T{
\fBEXIT_LIMITS\fP
T}:T{
Ressourcenbegrenzungen konnten nicht angepasst werden\&. Siehe \fILimitCPU=\fP und verwandte Einstellungen oben\&.
T}
T{
206
T}:T{
\fBEXIT_OOM_ADJUST\fP
T}:T{
OOM\-Einstellungen konnten nicht angepasst werden\&. Siehe \fIOOMScoreAdjust=\fP oben\&.
T}
T{
207
T}:T{
\fBEXIT_SIGNAL_MASK\fP
T}:T{
Prozesssignalmaske konnte nicht gesetzt werden\&.
T}
T{
208
T}:T{
\fBEXIT_STDIN\fP
T}:T{
Standardeingabe konnte nicht gesetzt werden\&. Siehe \fIStandardInput=\fP oben\&.
T}
T{
209
T}:T{
\fBEXIT_STDOUT\fP
T}:T{
Standardausgabe konnte nicht gesetzt werden\&. Siehe \fIStandardOutput=\fP oben\&.
T}
T{
210
T}:T{
\fBEXIT_CHROOT\fP
T}:T{
Würzelverzeichnis konnte nicht geändert werden (\fBchroot\fP(2))\&. Siehe \fIRootDirectory=\fP/\fIRootImage=\fP oben\&.
T}
T{
211
T}:T{
\fBEXIT_IOPRIO\fP
T}:T{
E/A\-Scheduling\-Priorität konnte nicht gesetzt werden\&. Siehe \fIIOSchedulingClass=\fP/\fIIOSchedulingPriority=\fP oben\&.
T}
T{
212
T}:T{
\fBEXIT_TIMERSLACK\fP
T}:T{
Failed to set up timer slack\&. See \fITimerSlackNSec=\fP above\&.
T}
T{
213
T}:T{
\fBEXIT_SECUREBITS\fP
T}:T{
Prozess\-Sicherheits\-Bits konnten nicht gesetzt werden\&. Siehe \fISecureBits=\fP oben\&.
T}
T{
214
T}:T{
\fBEXIT_SETSCHEDULER\fP
T}:T{
CPU\-Scheduling konnte nicht gesetzt werden\&. Siehe \fICPUSchedulingPolicy=\fP/\fICPUSchedulingPriority=\fP oben\&.
T}
T{
215
T}:T{
\fBEXIT_CPUAFFINITY\fP
T}:T{
CPU\-Affinität konnte nicht gesetzt werden\&. Siehe \fICPUAffinity=\fP oben\&.
T}
T{
216
T}:T{
\fBEXIT_GROUP\fP
T}:T{
Gruppen\-Zugangsdaten konnten nicht bestimmt oder geändert werden\&. Siehe \fIGroup=\fP/\fISupplementaryGroups=\fP oben\&.
T}
T{
217
T}:T{
\fBEXIT_USER\fP
T}:T{
Benutzer\-Zugangsdaten konnten nicht bestimmt oder geändert werden oder Benutzernamensräume eingerichtet werden\&. Siehe \fIUser=\fP/\fIPrivateUsers=\fP oben\&.
T}
T{
218
T}:T{
\fBEXIT_CAPABILITIES\fP
T}:T{
Capabilities konnten nicht abgegeben oder Umgebungs\-Capabilities angewandt werden\&. Siehe \fICapabilityBoundingSet=\fP/\fIAmbientCapabilities=\fP oben\&.
T}
T{
219
T}:T{
\fBEXIT_CGROUP\fP
T}:T{
Einrichten der Dienste\-Control\-Gruppe schlug fehl\&.
T}
T{
220
T}:T{
\fBEXIT_SETSID\fP
T}:T{
Erstellung einer neuen Prozesssitzung schlug fehl\&.
T}
T{
221
T}:T{
\fBEXIT_CONFIRM\fP
T}:T{
Ausführung wurde vom Benutzer abgebrochen\&. Siehe die Kernelbefehlszeileneinstellung \fIsystemd\&.confirm_spawn=\fP in \fBkernel\-command\-line\fP(7) für Details\&.
T}
T{
222
T}:T{
\fBEXIT_STDERR\fP
T}:T{
Standardfehlerausgabe konnte nicht eingerichtet werden\&. Siehe \fIStandardError=\fP oben\&.
T}
T{
224
T}:T{
\fBEXIT_PAM\fP
T}:T{
PAM\-Sitzung konnte nicht eingerichtet werden\&. Siehe \fIPAMName=\fP oben\&.
T}
T{
225
T}:T{
\fBEXIT_NETWORK\fP
T}:T{
Netzwerknamensräume konnten nicht eingericht werden\&. Siehe \fIPrivateNetwork=\fP oben\&.
T}
T{
226
T}:T{
\fBEXIT_NAMESPACE\fP
T}:T{
Einhängenamensräume konnten nicht eingerichtet werden\&. Siehe \fIReadOnlyPaths=\fP und verwandte Einstellungen oben\&
T}
T{
227
T}:T{
\fBEXIT_NO_NEW_PRIVILEGES\fP
T}:T{
Neue Privilegien konnten nicht deaktiviert werden\&. Siehe \fINoNewPrivileges=yes\fP oben\&.
T}
T{
228
T}:T{
\fBEXIT_SECCOMP\fP
T}:T{
Systemaufruffilter konnten nicht angewandt werden\&. Siehe \fISystemCallFilter=\fP und verwandte Einstellungen oben\&.
T}
T{
229
T}:T{
\fBEXIT_SELINUX_CONTEXT\fP
T}:T{
SELinux\-Kontext konnte nicht bestimmt oder geändert werden\& Siehe \fISELinuxContext=\fP oben\&.
T}
T{
230
T}:T{
\fBEXIT_PERSONALITY\fP
T}:T{
Ausführungsdomäne (Personalität) konnte nicht eingerichtet werden\&. Siehe \fIPersonality=\fP oben\&.
T}
T{
231
T}:T{
\fBEXIT_APPARMOR_PROFILE\fP
T}:T{
AppArmor konnte nicht vorbereitet werden\&. SIehe \fIAppArmorProfile=\fP oben\&.
T}
T{
232
T}:T{
\fBEXIT_ADDRESS_FAMILIES\fP
T}:T{
Adressfamilien konnten nicht beschränkt werden\&. Siehe \fIRestrictAddressFamilies=\fP oben\&.
T}
T{
233
T}:T{
\fBEXIT_RUNTIME_DIRECTORY\fP
T}:T{
Laufzeitverzeichnis konnte nicht eingerichtet werden\&. Siehe \fIRuntimeDirectory=\fP und verwandte Einstellungen oben\&.
T}
T{
235
T}:T{
\fBEXIT_CHOWN\fP
T}:T{
Socket\-Eigentümerschaft konnte nicht angepasst werden\&. Wird nur für Socket\-Units verwandt\&.
T}
T{
236
T}:T{
\fBEXIT_SMACK_PROCESS_LABEL\fP
T}:T{
SMACK\-Sicherheitskennzeichnung konnte nicht gesetzt werden\&. Siehe \fISmackProcessLabel=\fP oben\&.
T}
T{
237
T}:T{
\fBEXIT_KEYRING\fP
T}:T{
Kernel\-Schlüsselbund konnte nicht eingerichtet werden\&.
T}
T{
238
T}:T{
\fBEXIT_STATE_DIRECTORY\fP
T}:T{
Zustandsverzeichnis der Unit konnte nicht eingerichtet werden\&. Siehe \fIStateDirectory=\fP oben\&.
T}
T{
239
T}:T{
\fBEXIT_CACHE_DIRECTORY\fP
T}:T{
Zwischenspeicherverzeichnis der Unit konnte nicht eingerichtet werden\&. Siehe \fICacheDirectory=\fP oben\&.
T}
T{
240
T}:T{
\fBEXIT_LOGS_DIRECTORY\fP
T}:T{
Protokollierverzeichnis der Unit konnte nicht eingerichtet werden\&. Siehe \fILogsDirectory=\fP oben\&.
T}
T{
241
T}:T{
\fBEXIT_CONFIGURATION_DIRECTORY\fP
T}:T{
Konfigurationsverzeichnis der Unit konnte nicht eingerichtet werden\&. Siehe \fIConfigurationDirectory=\fP oben\&.
T}
.TE
.sp 1
.PP
Schließlich definieren die BSD\-Betriebssysteme eine Reihe von Exit\-Codes,
die typischerweise auch auf Linux\-Systemen definiert sind:
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTabelle\ \&9.\ \&BSD\-Exit\-Codes\fP
.TS
allbox tab(:);
lB lB lB.
T{
Exit\-Code
T}:T{
Symbolischer Name
T}:T{
Beschreibung
T}
.T&
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l
l l l.
T{
64
T}:T{
\fBEX_USAGE\fP
T}:T{
Befehlszeilenbenutzungsfehler
T}
T{
65
T}:T{
\fBEX_DATAERR\fP
T}:T{
Datenformatfehler
T}
T{
66
T}:T{
\fBEX_NOINPUT\fP
T}:T{
Eingabe kann nicht geöffnet werden
T}
T{
67
T}:T{
\fBEX_NOUSER\fP
T}:T{
Adresse unbekannt
T}
T{
68
T}:T{
\fBEX_NOHOST\fP
T}:T{
Rechnername unbekannt
T}
T{
69
T}:T{
\fBEX_UNAVAILABLE\fP
T}:T{
Dienst nicht verfügbar
T}
T{
70
T}:T{
\fBEX_SOFTWARE\fP
T}:T{
interner Softwarefehler
T}
T{
71
T}:T{
\fBEX_OSERR\fP
T}:T{
Systemfehler (d\&.h\&. Fork kann nicht ausgeführt werden)
T}
T{
72
T}:T{
\fBEX_OSFILE\fP
T}:T{
kritische Betriebssystemdatei fehlt
T}
T{
73
T}:T{
\fBEX_CANTCREAT\fP
T}:T{
(Benutzer)\-Ausgabedatei kann nicht erstellt werden
T}
T{
74
T}:T{
\fBEX_IOERR\fP
T}:T{
Eingabe/Ausgabe\-Fehler
T}
T{
75
T}:T{
\fBEX_TEMPFAIL\fP
T}:T{
Temporärer Fehlschlag, Benutzer sollte es noch einmal versuchen
T}
T{
76
T}:T{
\fBEX_PROTOCOL\fP
T}:T{
Ferner Fehler im Protokoll
T}
T{
77
T}:T{
\fBEX_NOPERM\fP
T}:T{
Erlaubnis verweigert
T}
T{
78
T}:T{
\fBEX_CONFIG\fP
T}:T{
Konfigurationsfehler
T}
.TE
.sp 1
.SH "SIEHE AUCH"
.PP
\fBsystemd\fP(1), \fBsystemctl\fP(1), \fBsystemd\-analyze\fP(1), \fBjournalctl\fP(1),
\fBsystemd\-system.conf\fP(5), \fBsystemd.unit\fP(5), \fBsystemd.service\fP(5),
\fBsystemd.socket\fP(5), \fBsystemd.swap\fP(5), \fBsystemd.mount\fP(5),
\fBsystemd.kill\fP(5), \fBsystemd.resource\-control\fP(5), \fBsystemd.time\fP(7),
\fBsystemd.directives\fP(7), \fBtmpfiles.d\fP(5), \fBexec\fP(3)
.SH ANMERKUNGEN
.IP " 1." 4
Spezifikation für auffindbare Partitionen
.RS 4
\%https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
.RE
.IP " 2." 4
Schalter »Keine neuen Privilegien«
.RS 4
\%https://www.kernel.org/doc/html/latest/userspace\-api/no_new_privs.html
.RE
.IP " 3." 4
proc.txt
.RS 4
\%https://www.kernel.org/doc/Documentation/filesystems/proc.txt
.RE
.IP " 4." 4
Base64
.RS 4
\%https://tools.ietf.org/html/rfc2045#section\-6.8
.RE
.IP " 5." 4
LSB\-Spezifikation
.RS 4
\%https://refspecs.linuxbase.org/LSB_5.0.0/LSB\-Core\-generic/LSB\-Core\-generic/iniscrptact.html
.RE

.SH Ü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>.