SYSTEMD.EXEC(5) systemd.exec SYSTEMD.EXEC(5) BEZEICHNUNG systemd.exec - Konfiguration der Ausfuhrungsumgebung UBERSICHT Dienst.service, Socket.socket, Einhangung.mount, Auslagerung.swap BESCHREIBUNG Unit-Konfigurationsdateien fur Dienste, Sockets, Einhangepunkte und Auslagerungsgerate nutzen eine Teilmenge der Konfigurationsoptionen, die die Ausfuhrungsumgebung von gestarteten Prozessen definieren. Diese Handbuchseite listet die Konfigurationsoptionen auf, die von diesen vier Unit-Typen gemeinsam benutzt werden. Siehe systemd.unit(5) fur die Konfiguration der von allen Unit-Typen gemeinsam benutzten Optionen und systemd.service(5), systemd.socket(5), systemd.swap(5) und systemd.mount(5) fur weitere Informationen uber die Konfigurationsdateioptionen, die fur jeden Unit-Typen spezifisch sind. Die ausfuhrungsspezifischen Konfigurationsoptionen werden in den Abschnitten [Service], [Socket], [Mount] oder [Swap] konfiguriert, abhangig vom Unit-Typ. Zusatzlich werden Optionen, die verfugbare Ressourcen mittels Linux Control Groups (cgroups) steuern, in systemd.resource-control(5) aufgefuhrt. Diese Optionen erganzen die hier aufgefuhrten Optionen. IMPLIZITE ABHANGIGKEITEN Einige Ausfuhrungsparameter fuhren zur Erganzung von zusatzlichen, automatischen Abhangigkeiten: o Units mit gesetzten WorkingDirectory=, RootDirectory=, RootImage=, RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory= oder ConfigurationDirectory= erhalten automatisch Abhangigkeiten vom Typ Requires= und After= von allen fur den Zugriff auf die festgelegten Pfade notwendigen Einhangepunkten. Dies ist aquivalent zur expliziten Auflistung in RequiresMountsFor=. o Ahnlich erhalten Einhange-Units mit aktiviertem PrivateTmp= automatisch Abhangigkeiten von allen Einhangungen, die notwendig sind, auf /tmp/ und /var/tmp/ zuzugreifen. Sie werden auch automatische Abhangigkeiten After= von systemd-tmpfiles-setup.service(8) erhalten. o Units, deren Standardausgabe oder Fehlerausgabe mit dem journal oder kmsg (oder ihrer Kombination mit Konsolenausgabe, siehe unten) verbunden ist, erlangen automatisch Abhangigkeiten vom Typ After= von systemd-journald.socket. o Units, die LogNamespace= verwenden, werden automatisch Ordnungs- und Bedingungsabhangigkeiten auf die zwei zugeordneten Socket-Units mit systemd-journald@.service-Instanzen erlangen. PFADE Die folgenden Einstellungen konnen zur Anderung der Sicht eines Dienstes auf das Dateisystem verwandt werden. Bitte beachten Sie, dass die Pfade absolut sein mussen und keine >>..<<-Pfadkomponente enthalten durfen. ExecSearchPath= Akzeptiert eine Doppelpunkt-getrennte Liste von absoluten Pfaden, relativ zu denen die durch Eigenschaften Exec*= (z.B. ExecStart=, ExecStop=, usw.) verwandten Programme gefunden werden konnen. ExecSearchPath= setzt $PATH ausser Kraft, falls $PATH nicht durch den Benutzer mittels Environment=, EnvironmentFile= oder PassEnvironment= bereitgestellt wird. Zuweisung einer leeren Zeichenkette entfernt vorherige Zuweisungen und mehrfaches Setzen von ExecSearchPath= auf einen Wert wird an die vorherigen Einstellungen anhangen. Hinzugefugt in Version 250. WorkingDirectory= Akzeptiert einen Verzeichnispfad, der relativ zu dem durch RootDirectory= festgelegten Wurzelverzeichnis des Dienstes ist, oder den besonderen Wert >>~<<. Setzt das Arbeitsverzeichnis fur ausgefuhrte Prozesse. Falls auf >>~<< gesetzt, wird das Home-Verzeichnis des in User= festgelegten Benutzers verwandt. Falls nicht gesetzt, ist dies standardmassig das Wurzelverzeichnis, falls Systemd als eine Systeminstanz lauft und das Home-Verzeichnis des respektiven Benutzers, falls es als Benutzer lauft. Falls der Einstellung das Zeichen >>-<< vorangestellt wird, wird ein fehlendes Arbeitsverzeichnis nicht als fatal betrachtet. Falls RootDirectory=/RootImage= nicht gesetzt ist, dann ist WorkingDirectory= relativ zu der Wurzel des Systems, das den Diensteverwalter betreibt. Beachten Sie, dass das Setzen dieses Parameters die Hinzunahme von zusatzlichen Abhangigkeiten (siehe oben) auslosen kann. RootDirectory= Akzeptiert einen Verzeichnispfad, der relativ zum Wurzelverzeichnis des Rechners (d.h. der Wurzel des Systems, auf dem der Diensteverwalter lauft) ist. Setzt mit dem Systemaufruf chroot(2) das Wurzelverzeichnis fur ausgefuhrte Prozesse. Falls dies verwandt wird, muss sichergestellt werden, dass das Prozessprogramm und alle seine zugehorigen Dateien in dem chroot()-Gefangnis verfugbar sind. Beachten Sie, dass das Setzen dieses Parameters die Hinzunahme von zusatzlichen Abhangigkeiten (siehe oben) auslosen kann. Die Einstellungen MountAPIVFS= und PrivateUsers= sind inbesondere im Zusammenhang mit RootDirectory= nutzlich. Fur Details siehe unten. Falls RootDirectory=/RootImage= zusammen mit NotifyAccess= verwandt werden, wird der Benachrichtigungs-Socket automatisch vom Rechner in die Wurzel-Umgebung eingehangt, um sicherzustellen, dass das Benachrichtigungs-Socket korrekt funktionieren kann. Beachten Sie, dass Dienste, die RootDirectory=/RootImage= verwenden, nicht in der Lage sein werden, uber das Syslog- oder Journal-Protokoll in die Protokollierinfrastruktur des Rechners zu protokollieren, ausser die relevanten Sockets vom Rechner sind eingehangt, konkret: Die Datei os-release(5) des Hauptsystems wird dem Dienst (schreibgeschutzt) als /run/host/os-release bereitgestellt. Sie wird beim weichen Neustart automatisch aktualisiert (siehe systemd-soft-reboot.service(8)), falls der Dienst so konfiguriert ist, dass er dies uberlebt. Beispiel 1. Einhangen von Protokollier-Sockets in die Wurzel-Umgebung BindReadOnlyPaths=/dev/log /run/systemd/journal/socket /run/systemd/journal/stdout Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). RootImage= Akzeptiert einen Pfad zu einem Blockgerateknoten oder einer regularen Datei als Argument. Dieser Aufruf ist ahnlich RootDirectory=, hangt allerdings eine Dateisystemhierarchie aus einem Blockgerateknoten oder einer Loopback-Datei anstatt eines Verzeichnisses ein. Der Gerateknoten oder die Dateisystemabbilddatei mussen ein Dateisystem ohne Partitionstabelle enthalten oder ein Dateisystem innerhalb einer MBR/MS-DOS- oder GPT-Partitionstabelle mit nur einer einzelnen Linux-kompatiblen Partition oder eine Gruppe von Dateisystemen innerhalb einer GPT-Partitionstabelle, die der Spezifikation fur auffindbare Partitionen[1] folgt. Wenn DevicePolicy= auf >>closed<< oder >>strict<< gesetzt ist oder auf >>auto<< und DeviceAllow= gesetzt ist, dann fugt diese Einstellung /dev/loop-control mit Modus rw, >>block-loop<< und >>block-blkext<< mit Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) fur die Details uber DevicePolicy= oder DeviceAllow=. Siehe auch nachfolgendes PrivateDevices=, da sie die Einstellungen von DevicePolicy= andern konnte. Units, die RootImage= verwenden, erlangen automatisch eine After=-Abhangigkeit auf systemd-udevd.service. Die Datei os-release(5) des Hauptsystems wird dem Dienst (schreibgeschutzt) als /run/host/os-release bereitgestellt. Sie wird beim weichen Neustart automatisch aktualisiert (siehe systemd-soft-reboot.service(8)), falls der Dienst so konfiguriert ist, dass er dies uberlebt. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 233. RootImageOptions= Akzeptiert eine Kommata-getrennte Liste von Einhangeoptionen, die bei mit RootImage= angegebenen Plattenabbildern verwandt werden. Optional kann ein Partitionsname vorangestellt werden, gefolgt von einem Doppelpunkt, falls das Abbild uber mehrere Partitionen verfugt, andernfalls wird der Partitionsname >>root<< angenommen. Optionen fur mehrere Partitionen konnen in einer einzelnen Zeile durch Leerzeichen getrennt angegeben werden. Durch Zuweisung einer leeren Zeichenkette werden die vorhergehenden Zuweisungen entfernt. Doppelte Optionen werden ignoriert. Bitte lesen Sie mount(8) fur eine Liste gultiger Einhangeoptionen. Gultige Partitionsnamen folgen der Spezifikation fur auffindbare Partitionen[1]: root, usr, home, srv, esp, xbootldr, tmp, var. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 247. RootEphemeral= Akzeptiert ein logisches Argument. Falls aktiviert, werden ausgefuhrte Prozesse in einer fluchtigen Kopie des Wurzelverzeichnisses oder Wurzelabbildes laufen. Die fluchtige Kopie liegt in /var/lib/systemd/ephemeral-trees/ wahrend der Dienst aktiv ist und wird bereinigt, wenn der Dienst gestoppt oder neu gestartet wird. Falls RootDirectory= verwandt wird und das Wurzelverzeichnis ein Unterdatentrager ist, wird die fluchtige Kopie durch Erstellen eines Schnappschusses des Unterdatentragers erstellt. Um sicherzustellen, dass fluchtige Kopien effizient erstellt werden, sollte sich das Wurzelverzeichnis oder Wurzelabbild auf dem gleichen Dateisystem wie /var/lib/systemd/ephemeral-trees/ befinden. Bei der Verwendung von RootEphemeral= mit Wurzeldateisystemen, sollte btrfs(5) als Dateisystem verwandt werden und das Wurzeldateisystem sollte idealerweise ein Unterdatentrager sein, von dem systemd einen Schnappschuss zur Erstellung der fluchtigen Kopie schiessen kann. Fur Wurzelabbilder sollte ein Dateisystem mit Unterstutzung fur >>reflinks<< verwandt werden, um eine effiziente fluchtige Kopie sicherzustellen. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 254. RootHash= Akzeptiert einen hexadezimal angegebenen Datenintegritats-Hash (dm-verity) fur die Wurzel oder den Pfad zu einer Datei, die einen ASCII-hexadezimal-formatierten Hash der Wurzel enthalt. Diese Option aktiviert Datenintegritatsuberprufungen mittels dm-verity, falls das verwandte Abbild die geeigneten Integritatsdaten enthalt (siehe oben) oder falls RootVerity= verwandt wird. Der angegebene Hash muss auf den Wurzel-Hash der Integritatsdaten passen und ist normalerweise 256 Bit (und damit 64 formatierte hexadezimale Zeichen) lang (im Falle von beispielsweise SHA256). Falls diese Option nicht angegeben ist aber die Abbilddatei ein erweitertes Dateiattribut >>user.verity.roothash<< tragt (siehe xattr(7)), dann wird der Wurzel-Hash daraus gelesen, auch als hexdezimal formatierte Zeichen. Falls das erweiterte Dateiattribut nicht gefunden wird (oder vom zugrundeliegenden Dateisystem nicht unterstutzt wird), aber eine Datei mit der Endung >>.roothash<< neben der Abbild-Datei gefunden wird, die anderweitig genau den gleichen Namen tragt (ausser falls das Abbild die Endung >>.raw<< tragt, dann darf die Wurzel-Hash-Datei dies nicht in ihrem Namen haben), wird der Wurzel-Hash daraus gelesen und automatisch verwandt, auch als hexadezimal formatierte Zeichen. Falls das Plattenabbild eine separate Partition fur /usr/ enthalt, konnte sie auch Verity-geschutzt sein. In diesem Fall konnte der Wurzel-Hash auch uber ein erweitertes Attribut >>user.verity.usrhash<< oder eine Datei .usrhash in der Nahe des Plattenabbildes konfiguriert sein. Derzeit gibt es keine Option, um den Wurzel-Hash fur das Dateisystem /usr/ mittels der Unit-Datei direkt zu konfigurieren. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 246. RootHashSignature= Akzeptiert eine PKCS7-Signatur der Option RootHash= als Pfad zu einer DER-kodierten Signatur oder als eine ASCII-Base64-Zeichenkette, die eine DER-kodierte Signatur kodiert, der >>base64<< vorangestellt ist. Der dm-verity-Datentrager wird nur geoffnet, falls die Signatur des Wuzel-Hashes gultig ist und von einem offentlichen Schlussel signiert wurde, der im Kernel-Schlusselbund enthalten ist. Falls diese Option nicht angegeben ist, aber eine Datei mit der Endung >>.roothash.p7s<< neben der Abbild-Datei gefunden wird, die anderweitig genau den gleichen Namen tragt (ausser falls das Abbild die Endung >>.raw<< tragt, dann darf die Signaturdatei dies nicht in ihrem Namen haben), dann wird die Signatur daraus gelesen und automatisch verwandt. Falls das Plattenabbild eine separate Partition fur /usr/ enthalt, konnte sie auch Verity-geschutzt sein. In diesem Fall konnte die Signatur fur den Wurzel-Hash auch uber eine Datei .usrhash.p7s in der Nahe des Plattenabbildes konfiguriert sein. Derzeit gibt es keine Option, um die Wurzel-Hash-Signatur fur das Dateisystem /usr/ mittels der Unit-Datei direkt zu konfigurieren. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 246. RootVerity= Akzeptiert einen Pfad zu einer Datenintegritats- (dm-verity-)Datei. Diese Option aktiviert Datenintegritatsuberprufungen mittels dm-verity, falls RootImage= verwandt wird und ein Wurzel-Hash ubergeben wird und falls das verwandte Abbild selbst keine Integritatsdaten enthalt. Die Integritatsdaten mussen auf den Wurzel-Hash passen. Falls diese Option nicht angegeben ist, aber eine Datei mit der Endung >>.verity<< neben der Abbild-Datei gefunden wird, die anderweitig genau den gleichen Namen tragt (ausser falls das Abbild die Endung >>.raw<< tragt, dann darf die Signaturdatei dies nicht in ihrem Namen haben), dann werden die Verity-Daten daraus gelesen und automatisch verwandt. Diese Option wird nur fur Plattenabbilder unterstutzt, die ein einzelnes Dateisystem, ohne umhullende Partitionstabelle, enthalten. Abbilder, die eine GPT-Partitionstabelle enthalten, sollten stattdessen sowohl ein Wurzeldateisystem als auch passende Verity-Daten im gleichen Abbild enthalten, und damit die Spezifikation fur auffindbare Partitionen[1] umsetzen. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 246. RootImagePolicy=, MountImagePolicy=, ExtensionImagePolicy= Akzeptiert eine Abbildrichtlinienzeichenkette gemass systemd.image-policy(7), die beim Einhangen eines in RootImage=, MountImage= bzw. ExtensionImage= festgelegten Plattenabbildes verwandt werden soll. Falls sie nicht angegeben ist, ist die folgende Richtlinienzeichenkette die Vorgabe fur RootImagePolicy= und MountImagePolicy: root=verity+signed+encrypted+unprotected+absent: \ usr=verity+signed+encrypted+unprotected+absent: \ home=encrypted+unprotected+absent: \ srv=encrypted+unprotected+absent: \ tmp=encrypted+unprotected+absent: \ var=encrypted+unprotected+absent Die Vorgaberichtlinie fur ExtensionImagePolicy= ist: root=verity+signed+encrypted+unprotected+absent: \ usr=verity+signed+encrypted+unprotected+absent Hinzugefugt in Version 254. MountAPIVFS= Akzeptiert ein logisches Argument. Falls eingeschaltet, wird ein privater Einhangenamensraum fur die Prozesse der Unit erstellt und die API-Dateisysteme /proc/, /sys/, /dev/ und /run/ (als ein leeres >>tmpfs<<) darin eingehangt, ausser sie sind bereits eingehangt. Beachten Sie, dass diese Option keinen Effekt zeigt, ausser sie wird zusammen mit RootDirectory=/RootImage= verwandt, da diese vier Einhangungen im Allgemeinen im Rechner sowieso eingehangt sind und ausser wenn das Wurzelverzeichnis geandert wird, der private Einhangenamensraum eine 1:1-Kopie des Rechners sein wird und diese vier Einhangungen enthalten wird. Beachten Sie, dass das /dev/-Dateisystem des Rechners mit >>bind<< eingehangt wird, falls diese Option ohne PrivateDevices= verwandt wird. Um den Dienst mit einer privaten, minimalen Version von /dev/ auszufuhren, kombinieren Sie diese Option mit PrivateDevices=. Um die sichere Einhangeausbreitung zur Laufzeit zu ermoglichen, wird auf dem Rechner /run/systemd/propagate/ zur Einrichtung neuer Einhangungen und im privaten Namensraum /run/host/incoming/ als Zwischenschritt verwandt, um diese zu speichern, bevor sie auf den endgultigen Einhangepunkt verschoben werden. Hinzugefugt in Version 233. ProtectProc= Akzeptiert entweder >>noaccess<<, >>invisible<<, >>ptraceable<< oder >>default<< (die Vorgabe). Wenn gesetzt, steuert dies die Einhangeoption >>hidepid=<< der >>procfs<<-Instanz fur die Unit, die steuert, welche Verzeichnisse mit Prozessmetainformationen (/proc/PID) sichtbar und zugreifbar sind: wird dies auf >>noaccess<< gesetzt, dann wird die Fahigkeit, auf die meisten Prozessmetadaten anderer Prozesse in /proc/ zuzugreifen, fur Prozesse des Dienstes entfernt. Wird dies auf >>invisible<< gesetzt, dann werden die meisten Prozesse, die anderen Benutzern gehoren, in /proc/ versteckt. Bei >>ptraceable<< werden alle Prozesse, die nicht mit ptrace() untersucht werden konnen, davor versteckt. Bei >>default<< werden keine Einschrankungen beim Zugriff auf /proc/ oder dessen Sichtbarkeit vorgenommen. Fur weitere Details siehe Das /proc-Dateisystem[2]. Es wird im Allgemeinen empfohlen, die meisten Systemdienste so auszufuhren, dass diese Option auf >>invisible<< gesetzt ist. Diese Option wird mittels Dateisystemnamensraumen implementiert und kann daher nicht mit Diensten verwandt werden, die in der Lage sein mussen, Einhangepunkte in der Dateisystemhierarchie des Wirts zu installieren. Beachten Sie, dass der Benutzer >>root<< von dieser Option nicht betroffen ist, um daher wirksam zu sein, muss sie zusammen mit User= oder DynamicUser=yes und auch ohne die Capability >>CAP_SYS_PTRACE<< verwandt werden, da letztere Capability es einem Prozess erlaubt, diese Funktionalitat zu umgehen. Sie kann nicht fur Dienste verwandt werden, die auf Metainformationen von Prozessen anderer Benutzer zugreifen mussen. Diese Option impliziert MountAPIVFS=. Falls der Kernel keine einhangepunktbezogenen Einhangeoptionen hidepid= unterstutzt, dann bleibt diese Einstellung ohne Auswirkung und die Prozesse der Unit werden in der Lage sein, andere Prozesse zu sehen und auf sie zuzugreifen, als ob diese Option nicht verwandt worden ware. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 247. ProcSubset= Akzeptiert >>all<< (die Vorgabe) und >>pid<<. Falls >>pid<<, werden alle Dateien und Verzeichnisse, die nicht direkt der Prozessverwaltung und -prufung zugeordnet sind, im Dateisystem /proc/, das fur diese Prozesse konfiguriert wird, unsichtbar gemacht. Das steuert die Einhangeoption >>subset=<< der Instanz >>procfs<< fur diese Unit. Fur weitere Details siehe Das /proc-Dateisystem[2]. Beachten Sie, dass Linux verschiedene Kernel-APIs uber /proc/ offenlegt, die durch diese Einstellung unverfugbar gemacht werden. Da diese APIs haufig verwandt werden, ist diese Option nur in wenigen, besonderen Fallen nutzlich und nicht fur die meisten nicht-trivialen Programme geeignet. Ganz ahnlich zu obigem ProtectProc= wird dies mittels Namensraumen fur Dateisysteme implementiert und daher gelten die gleichen Einschrankungen: es ist nur fur Systemdienste verfugbar und deaktiviert die Einhangeweiterleitung an die Einhangetabelle des Rechners und es implementiert MountAPIVFS=. Diese Einstellung wird wie bei ProtectProc= auch sauber beendet, falls der Kernel die Einhangeoption >>subset=<< von >>procfs<< nicht unterstutzt.. Hinzugefugt in Version 247. BindPaths=, BindReadOnlyPaths= Konfiguriert Unit-spezifische Bind-Einhangungen. Eine Bind-Einhangung macht eine bestimmte Datei oder Verzeichnis an einem zusatzlichen Ort in der Betrachtung der Unit verfugbar. Alle mit dieser Option erstellten Bind-Einhangungen sind fur die Unit spezifisch und nicht innerhalb der Einhangetabelle des Rechners sichtbar. Diese Option erwartet eine Leerraum-getrennte Liste von Bind-Einhangedefinitionen. 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-Einhangung zu konfigurieren. Falls der Zielpfad ausgelassen wird, muss auch die Optionszeichenkette ausgelassen werden. Jeder Bind-Einhangungsdefinition kann >>-<< vorangestellt werden, wodurch sie ignoriert wird, falls der Quellpfad nicht existiert. BindPaths= erstellt regulare, schreibbare Bind-Einhangungen (ausser die Quelldateisystemeinhangung ist bereits nur-lesbar markiert), wahrend BindReadOnlyPaths= nur-lesbare Bind-Einhangungen erstellt. Diese Einstellungen konnen mehr als einmal verwandt werden, jede Verwendung hangt sich an die Liste der Bind-Einhangungen der Unit an. Falls zu einer dieser zwei Optionen die leere Zeichenkette zugewiesen wird, wird die gesamte Liste an vorher definierten Bind-Einhangungen dazu zuruckgesetzt. Beachten Sie, dass in diesem Fall sowohl die nur-lesbaren als auch die regularen Bind-Einhangungen zuruckgesetzt werden, unabhangig davon, welche der zwei Einhangungen verwandt wird. Diese Option ist besonders nutzlich, wenn RootDirectory=/RootImage= verwandt wird. In diesem Fall bezieht sich der Quellpfad auf einen Pfad im Dateisystem des Rechners, wahrend der Zielpfad sich auf einen Pfad unterhalb des Wurzelverzeichnisses der Unit bezieht. Beachten Sie, dass das Zielverzeichnis existieren oder Systemd in der Lage sein muss, es zu erstellen. Daher ist es nicht moglich, diese Option fur Einhangepunkte, die unterhalb von in InaccessiblePaths= oder unter /home/ und anderen geschutzten Verzeichnissen verschachtelt sind, zu verwenden, falls ProtectHome=yes angegeben ist. Stattdessen sollte TemporaryFileSystem= mit >>:ro<< oder ProtectHome=tmpfs verwandt werden. Hinzugefugt in Version 233. MountImages= Diese Einstellung ist ahnlich zu RootImage=. Sie hangt eine Dateisystemhierarchie von einem Blockgerateknoten oder Loopack-Gerate ein, aber das Ziel-Verzeichnis sowie die Einhangeoptionen konnen angegeben werden. Diese Option erwartet ein durch Leerraum getrennte Liste von Einhangedefinitionen. Jede Definition besteht aus einem Doppelpunkt-getrennten Tupel von Quellpfad- und -Ziel-Definitionen, optional gefolgt durch einen weiteren Doppelpunkt und einer Liste von Einhangeoptionen. Einhangeoptionen konnen als eine durch einzelne Kommata getrennte Liste von Optionen definiert werden. In diesem Fall werden sie implizit auf die Wurzelpartition auf dem Abbild angewandt. Alternativ kann eine Reihe von Doppelpunkt-getrennten Tupeln von Partitionsnamen und Einhangeoptionen angegeben werden. Gultige Partitionsnamen und -Einhangeoptionen sind zu der oben beschriebenen Einstellung RootImageOptions= identisch. Jeder Einhangedefinition darf ein >>-<< vorangestellt werden. In diesem Fall wird sie ignoriert, falls sein Quellpfad nicht existiert. Das Quellargument ist ein Pfad zu einem Blockgerateknoten oder einer regularen Datei. Falls die Quelle oder das Ziel ein >>:<< enthalt, muss dieses mit >>\:<< maskiert werden. Der Gerateknoten oder das Dateisystemabbild muss den gleichen Regeln folgen, wie diese fur RootImage= spezifiziert sind. Alle Einhangungen, die mit dieser Option erstellt sind, sind spezifisch fur die Unit, und konnen in der Einhangetabelle des Rechners nicht gesehen werden. Diese Einstellung kann mehr als einmal verwandt werden. Jede Verwendung wird an die Liste der Einhangepfade der Unit angehangt. Falls die leere Zeichenkette zugewiesen wird, wird die gesamte Liste der Einhangepfade, die vorher definiert wurde, zuruckgesetzt. Beachten Sie, dass das Zielverzeichnis existieren oder Systemd in der Lage sein muss, es zu erstellen. Daher ist es nicht moglich, diese Option fur Einhangepunkte, die unterhalb von in InaccessiblePaths= oder unter /home/ und anderen geschutzten Verzeichnissen verschachtelt sind, zu verwenden, falls ProtectHome=yes angegeben ist. Wenn DevicePolicy= auf >>closed<< oder >>strict<< gesetzt ist oder auf >>auto<< und DeviceAllow= gesetzt ist, dann fugt diese Einstellung /dev/loop-control mit Modus rw, >>block-loop<< und >>block-blkext<< mit Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) fur die Details uber DevicePolicy= oder DeviceAllow=. Siehe auch nachfolgendes PrivateDevices=, da sie die Einstellungen von DevicePolicy= andern konnte. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 247. ExtensionImages= Diese Einstellung ist ahnlich zu MountImages=. Sie hangt eine Dateisystemhierarchie von einem Blockgerateknoten oder Loopack-Gerate ein, aber anstatt ein Ziel-Verzeichnis bereitzustellen, wird eine Uberlagerung eingerichtet. Diese Option erwartet eine durch Leerraum getrennte Liste von Einhangedefinitionen. Jede Definition besteht aus einem Quellpfad, optional gefolgt von einem Doppelpunkt und einer Liste von Einhangeoptionen. Es wird ein nur lesbares OverlayFS oberhalb der Hierarchien /usr/ und /opt/ fur Sysext-Abbilder und der Hierarchie /etc/ fur Confext-Abbilder eingerichtet. Die Reihenfolge, in der die Abbilder aufgefuhrt sind, wird die Reihenfolge bestimmen, in der die Uberlagerung aufgebaut ist: das zuerst angegebene Abbild ist auf unterster Ebene im OverlayFS und spatere sind entsprechend daruber bis ganz oben. Einhangeoptionen konnen als eine durch einzelne Kommata getrennte Liste von Optionen definiert werden. In diesem Fall werden sie implizit auf die Wurzelpartition auf dem Abbild angewandt. Alternativ kann eine Reihe von Doppelpunkt-getrennten Tupeln von Partitionsnamen und Einhangeoptionen angegeben werden. Gultige Partitionsnamen und -Einhangeoptionen sind zu der oben beschriebenen Einstellung RootImageOptions= identisch. Jeder Einhangedefinition darf ein >>-<< vorangestellt werden. In diesem Fall wird sie ignoriert, falls sein Quellpfad nicht existiert. Das Quellargument ist ein Pfad zu einem Blockgerateknoten oder einer regularen Datei. Falls der Quellpfad ein >>:<< enthalt, muss dieses mit >>\:<< maskiert werden. Der Gerateknoten oder das Dateisystemabbild muss den gleichen Regeln folgen, wie diese fur RootImage= spezifiziert sind. Alle Einhangungen, die mit dieser Option erstellt sind, sind spezifisch fur die Unit, und konnen in der Einhangetabelle des Rechners nicht gesehen werden. Diese Einstellung kann mehr als einmal verwandt werden. Jede Verwendung wird an die Liste der Abbildpfade der Unit angehangt. Falls die leere Zeichenkette zugewiesen wird, wird die gesamte Liste der Einhangepfade, die vorher definiert wurde, zuruckgesetzt. Jede Sysext-Abbilddatei muss eine Datei /usr/lib/extension-release.d/extension-release.IMAGE transportieren, wahrend Confext-Abbilder eine Datei /etc/extension-release.d/extension-release.IMAGE transportieren mussen, mit den geeigneten Metadaten, die auf RootImage=/RootDirectory= oder den Rechner passen. Siehe os-release(5). Um die Sicherheitsuberprufung, dass der Dateiname der Erweiterungs-Release-Datei auf den Namen der Abbild-Datei passt, zu deaktivieren, kann die Einhangeoption x-systemd.relax-extension-release-check angehangt werden. Wenn DevicePolicy= auf >>closed<< oder >>strict<< gesetzt ist oder auf >>auto<< und DeviceAllow= gesetzt ist, dann fugt diese Einstellung /dev/loop-control mit Modus rw, >>block-loop<< und >>block-blkext<< mit Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) fur die Details uber DevicePolicy= oder DeviceAllow=. Siehe auch nachfolgendes PrivateDevices=, da sie die Einstellungen von DevicePolicy= andern konnte. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 248. ExtensionDirectories= Diese Einstellung ist ahnlich zu BindReadOnlyPaths=. Sie hangt eine Dateisystemhierarchie von einem Verzeichnis ein, aber anstatt ein Ziel-Verzeichnis bereitzustellen, wird eine Uberlagerung eingerichtet. Diese Option erwartet eine durch Leerraum getrennte Liste von Quellverzeichnissen. Es wird ein nur lesbares OverlayFS oberhalb der Hierarchien /usr/ und /opt/ fur Sysext-Abbilder und oberhalb der Hierarchie /etc/ fur Confext-Abbilder eingerichtet. Die Reihenfolge, in der die Verzeichnisse aufgefuhrt sind, wird die Reihenfolge bestimmen, in der die Uberlagerung aufgebaut ist: das zuerst angegebene Verzeichnis ist auf unterster Ebene im OverlayFS und spatere sind entsprechend daruber bis ganz oben. Jedem in ExtensionDirectories= aufgefuhrten Verzeichnis darf ein >>-<< vorangestellt werden. In diesem Fall wird es ignoriert, falls sein Quellpfad nicht existiert. Alle Einhangungen, die mit dieser Option erstellt sind, sind spezifisch fur die Unit, und konnen in der Einhangetabelle des Rechners nicht gesehen werden. Diese Einstellung kann mehr als einmal verwandt werden. Jede Verwendung wird an die Liste der Verzeichnispfade der Unit angehangt. Falls die leere Zeichenkette zugewiesen wird, wird die gesamte Liste der Einhangepfade, die vorher definiert wurde, zuruckgesetzt. Jedes Sysext-Verzeichnis muss eine Datei /usr/lib/extension-release.d/extension-release.IMAGE enthalten, wahrend jedes Confext-Verzeichnis eine Datei /etc/extension-release.d/extension-release.IMAGE enthalten muss, mit den geeigneten Metadaten, die auf RootImage=/RootDirectory= oder den Rechner passen. Siehe os-release(5). Beachten Sie, dass die Verwendung aus Benutzer-Units die Unterstutzung von Overlayfs in nicht privilegierten Benutzernamensraumen benotigt, welche erstmalig in Kernel v5.11. eingefuhrt wurde. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 251. BENUTZER-/GRUPPEN-IDENTITATEN Diese Optionen sind nur fur Systemdienste verfugbar und werden nicht fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstutzt. User=, Group= Setzt den UNIX-Benutzer oder die -Gruppe, unter der der Prozess ausgefuhrt wird. Akzeptiert einen einzelnen Benutzer- oder Gruppennamen oder eine numerische Kennung als Argument. Fur Systemdienste (Dienste, die vom Systemdiensteverwalter, d.h. PID 1, ausgefuhrt werden) und fur Benutzerdienste des Benutzers root (Dienste, die von der Instanz von root von systemd --user verwaltet werden) ist die Vorgabe >>root<<, aber User= kann zur Angabe eines anderen Benutzers verwandt werden. Fur Benutzerdienste von allen anderen Benutzern ist das Umschalten auf eine andere Benutzeridentitat nicht erlaubt, daher ist die einzige gultige Einstellung der Benutzer, unter dem der Diensteverwalter selbst lauft. Falls keine Gruppe gesetzt ist, wird die Vorgabegruppe des Benutzers verwandt. Diese Einstellung beeinflusst keine Befehle, deren Befehlszeile ein >>+<< vorangestellt ist. Beachten Sie, dass dies nur schwache Einschrankungen in der Namenssyntax von Benutzer/Gruppen erzwingt, aber in vielen Fallen Warnungen erzeugt, bei denen Benutzer-/Gruppennamen nicht den folgenden Regeln genugen: der angegebene Name sollte nur aus den Zeichen a-z, A-Z, 0-9, >>_<< und >>-<< (ausser beim ersten Zeichen, das eines aus a-z, A-Z oder >>_<< sein muss, d.h. Zahlen und >>-<< sind als erstes Zeichen nicht erlaubt) bestehen. Der Benutzer-/Gruppenname muss mindestens ein und maximal 31 Zeichen enthalten. Diese Einschrankungen erfolgen, um Mehrdeutigkeiten zu vermeiden und um sicherzustellen, dass Benutzer-/Gruppennamen und Unit-Dateien zwischen Linux-Systemen portierbar bleiben. Fur weitere Details uber die akzeptierten Namen und die Namen, uber die gewarnt wird, siehe Benutzer-/Gruppennamesyntax[3]. Wenn dies zusammen mit DynamicUser= verwandt wird, wird der angegebene Benutzer-/Gruppename dynamisch zum Startzeitpunkt des Dienstes zugewiesen und beim Beenden des Dienstes wieder freigegeben -- ausser er ist bereits statisch zugewiesen (siehe unten). Falls DynamicUser= nicht verwandt wird, muss der angegebene Benutzer und die angegebene Gruppe spatestens beim Startmoment des Dienstes statisch in der Benutzerdatenbank erzeugt worden sein, beispielsweise mit der Einrichtung sysusers.d(5), die beim Systemstart oder zum Zeitpunkt der Paketinstallation angewandt wird. Falls der Benutzer nicht existiert, wird der Programmaufruf fehlschlagen. Falls die Einstellung User= verwandt wird, wird die Liste der zusatzlichen Gruppen aus der festgelegten Standardgruppenliste des Benutzers, wie dies durch die Benutzer- und Gruppendatenbank des Systems definiert ist, initialisiert. Zusatzliche Gruppen konnen durch die Einstellung SupplementaryGroups= konfiguriert werden (siehe unten). DynamicUser= Akzeptiert einen logischen Parameter. Falls gesetzt, wird ein UNIX-Benutzer-/Gruppenpaar dynamisch beim Start der Unit erstellt und wieder freigegeben, sobald die Unit beendet wird. Der Benutzer und die Gruppe wird nicht zu /etc/passwd oder /etc/group hinzugefugt, sondern zur Laufzeit vorubergehend verwaltet. Das Glibc-NSS-Modul nss-systemd(8) stellt eine Integration dieser dynamischen Benutzer/Gruppen in die Benutzer- und Gruppendatenbanken des Systems bereit. Die Benutzer- und Gruppennamen konnen mit User= und Group= (siehe oben) konfiguriert werden. Falls diese Optionen nicht verwandt werden und dynamische Benutzer-/Gruppenzuweisung fur 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 gultiger Benutzername geeignet ist, wird er direkt verwandt, andernfalls wird ein Name, der einen Hash davon integriert, verwandt. Falls ein statisch zugewiesener Benutzer oder eine statisch zugewiesene Gruppe des konfigurierten Namens bereits existiert, wird diese verwandt und kein dynamischer Benutzer/keine dynamische Gruppe wird zugewiesen. Beachten Sie, dass es notwendig ist, dass der statische Benutzer mit dem Namen bereits existiert, falls User= angegeben wurde und die statische Gruppe mit dem Namen bereits existiert. Entsprechend ist es notwendig, dass die statische Gruppe mit dem Namen bereits existiert, falls Group= angegeben wurde und der statische Benutzer mit dem Namen bereits existiert. Dynamische Benutzer/Gruppen werden aus dem UID/GID-Bereich 6118465519 zugewiesen. Es wird empfohlen, diesen Bereich fur regulare 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 lauft, fur die dynamische Benutzer/Gruppen aktiviert sind, keine Dateien oder Verzeichnisse, die diesen Benutzern/Gruppen gehoren, zurucklasst, da eine andere Unit spater die gleiche UID/GID zugewiesen bekommen kann, und daher Zugriff auf diese Dateien oder Verzeichnisse erlangen kann. Die Aktivierung von DynamicUser= impliziert RemoveIPC= und PrivateTmp= (was nicht deaktiviert werden kann). Dies stellt sicher, dass die Lebensdauer von IPC-Objekten und temporaren Dateien, die von dem ausgefuhrten Prozess erstellt wurden, an die Laufzeit des Dienstes gebunden ist, und damit die Lebensdauer des dynamischen Benutzers/der dynamischen Gruppe. Da /tmp/ und /var/tmp/ normalerweise die einzigen global schreibbar Verzeichnisse auf einem System sind, stellt dies sicher, dass eine Unit, die dynamische Benutzer-/Gruppenzuweisungen einsetzt, keine Dateien nach der Beendigung hinterlassen kann. Desweiteren werden NoNewPrivileges= und RestrictSUIDSGID= implizit aktiviert (und konnen nicht deaktiviert werden), um sicherzustellen, dass aufgerufene Prozesse nicht aus SUID/SGID-Dateien oder Verzeichnissen Nutzen ziehen oder diese erstellen konnen. Daruberhinaus sind ProtectSystem=strict und ProtectHome=read-only impliziert, die damit verhindern, dass der Dienst an beliebige Dateisystemstellen schreibt. Um dem Dienst das Schreiben in bestimmte Verzeichnisse zu erlauben, mussen diese mittels ReadWritePaths= explizit erlaubt werden; dabei ist drauf zu achten, dass die Wiederbenutzung von UIDs/GIDs keine Sicherheitsprobleme mit vom Dienst erstellten Dateien hervorruft. Verwenden Sie RuntimeDirectory= (siehe unten), um dem Dienst ein schreibbares Laufzeitverzeichnis zuzuweisen, das von dem dynamischen Benutzer/der dynamischen Gruppe besessen und automatisch beim Beenden der Unit entfernt wird. Verwenden Sie StateDirectory=, CacheDirectory= und LogsDirectory=, um eine Gruppe an schreibbaren Verzeichnissen fur einen bestimmten Zweck dem Dienst zuzuweisen und dabei sicherzustellen, dass sie vor Schwachstellen aufgrund der UID-Wiederbenutzung geschutzt sind (siehe unten). Falls diese Option aktiviert ist, sollte aufgepasst werden, dass die Prozesse der Unit keinen Zugriff auf Verzeichnisse ausserhalb dieser explizit konfigurierten und verwalteten bekommen. Verwenden Sie inbesondere nicht BindPaths= und seien Sie vorsichtig mit der Ubergabe von AF_UNIX-Dateideskriptoren fur Verzeichnisdateideskriptoren, da dieses Prozessen erlauben wurde, Dateien oder Verzeichnisse zu erstellen, die dem dynamischen Benutzer/der dynamischen Gruppe gehoren und nicht dem Lebenszyklus und den Zugriffsgarantien des Dienstes unterliegen. Beachten Sie, dass diese Option derzeit inkompatibel zu D-Bus-Richtlinien ist. Daher konnte ein Dienst, der diese Option verwendet, derzeit keinen D-Bus-Dienstenamen reservieren. Beachten Sie, dass dies nicht den Aufruf anderer D-Bus-Dienste beeintrachtigt. Standardmassig >>off<<. Hinzugefugt in Version 232. SupplementaryGroups= Setzt die zusatzlichen Gruppen, unter denen die Prozesse ausgefuhrt werden. Dies akzeptiert eine Leerzeichen-getrennte Liste von Gruppennamen oder -Kennungen. Diese Option kann mehr als einmal angegeben werden, dann werden alle aufgefuhrten Gruppen als zusatzliche Gruppen gesetzt. Wird die leere Zeichenkette zugewiesen, dann wird die Liste der zusatzlichen Gruppen zuruckgesetzt und alle Zuweisungen davor werden unwirksam. Auf jeden Fall setzt diese Option nicht die Liste der in der Systemgruppendatenbank fur den Benutzer konfigurierten zusatzlichen Gruppen ausser Kraft sondern erweitert sie. Dies betrifft nicht Befehle, denen >>+<< vorangestellt ist. SetLoginEnvironment= Dieser logische Parameter steuert, ob die Umgebungsvariablen $HOME, $LOGNAME und $SHELL gesetzt werden. Falls nicht gesetzt, wird dies dadurch gesteuert, ob User= gesetzt ist. Falls wahr, werden sie fur Systemdienste immer gesetzt, d.h. selbst wenn der Standardbenutzer >>root<< verwandt wird. Falls falsch, werden die aufgefuhrten Variablen durch Systemd nicht gesetzt, unabhangig davon, ob User= verwandt wird oder nicht. Diese Option hat bei Benutzerdiensten normalerweise keine Auswirkung, da diese Variablen sowieso typischerweise von der eigenen Umgebung des Benutzerverwalters geerbt werden. Hinzugefugt in Version 255. PAMName= Setzt den PAM-Dienstenamen, um darunter eine Sitzung einzurichten. Falls gesetzt, wird der ausgefuhrte Prozess als eine PAM-Sitzung unter dem festgelegten Dienstenamen registriert. Dies ist nur in Zusammenspiel mit der Einstellung User= nutzlich und wird sonst ignoriert. Falls nicht gesetzt, wird keine PAM-Sitzung fur den ausgefuhrten Prozess eroffnet. Siehe pam(8) fur Details. Beachten Sie, dass fur 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 konnen, wenn die Unit und damit die PAM-Sitzung beendet wird. Dieser Prozess heisst >>(sd-pam)<< und ist ein direkter Kindprozess des Hauptprozesses der Unit. Beachten Sie, dass es sehr wahrscheinlich ist (abhangig von der PAM-Konfiguration), dass der Haupt-Unit-Prozess in seine eigene Sitzungsgeltungsbereich-Unit migriert wird, wenn diese Option fur eine Unit verwandt und sie aktiviert wird. Dieser Prozess wird daher zwei Units zugeordnet sein: der Unit, in der er ursprunglich gestartet wurde (und fur die PAMName= konfiguriert wurde) und der Sitzungsgeltungsbereichs-Unit. Jeder Kindprozess dieses Prozesses wird allerdings nur der Sitzungsgeltungsbereichs-Unit zugeordnet sein. Dies hat Auswirkungen, wenn das in Kombination mit NotifyAccess=all verwandt wird, da diese Kindprozesse nicht in der Lage sein werden, Anderungen an der usprunglichen Unit uber Benachrichtigungsmeldungen zu erreichen. Es wird angenommen, dass diese Nachrichten zu der Sitzungsgeltungsbereichs-Unit und nicht der ursprunglichen Unit gehoren. Es wird daher nicht empfohlen, PAMName= in Kombination mit NotifyAccess=all zu verwenden. CAPABILITIES Diese Optionen sind nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= implizit aktiviert (benotigt Unterstutzung fur nicht privilegierte Benutzernamensraume im Kernel mittels des Sysctl >>.kernel.unprivileged_userns_clone=<<). CapabilityBoundingSet= Steuert, welche Capabilities in der Capability-Begrenzungsmenge fur den ausgefuhrten Prozess aufgenommen werden. Siehe capabilities(7) fur Details. Akzeptiert eine Leerzeichen-getrennte Liste von Capability-Namen, z.B. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. Aufgefuhrte Capabilities werden in die Begrenzungsmenge aufgenommen, alle anderen werden entfernt. Falls der Liste von Capabilities >>~<< vorangestellt wird, werden alle bis auf die aufgefuhrten 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 Prozessausfuhrung nicht verandert, daher werden keine Begrenzungen bezuglich der Capabilities des Prozesses erzwungen. Diese Option kann mehr als einmal auftauchen, die Begrenzungsmengen werden mit ODER zusammengefuhrt oder mit UND, falls den Zeilen >>~<< vorangestellt wird (siehe unten). Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Begrenzungsmenge auf die leere Capability-Menge zuruckgesetzt und alle vorhergehenden Einstellungen haben keine Wirkung. Falls auf >>~<< (ohne weiteres Argument) gesetzt, wird die Begrenzungsmenge auf die komplette Menge der verfugbaren Capabilities zuruckgesetzt und alle vorhergehenden Einstellungen zuruckgenommen. Dies betrifft nicht Befehle, denen >>+<< vorangestellt wurde. Verwenden Sie den Befehl capability von systemd-analyze(1), um eine Liste von Capabilities abzufragen, die auf dem lokalen System definiert sind. Beispiel: Falls eine Unit die Einstellunng CapabilityBoundingSet=CAP_A CAP_B CapabilityBoundingSet=CAP_B CAP_C hat, dann werden CAP_A, CAP_B und CAP_C gesetzt. Falls der zweiten Zeile >>~<< vorangestellt wird, d.h. CapabilityBoundingSet=CAP_A CAP_B CapabilityBoundingSet=~CAP_B CAP_C dann wird nur CAP_A gesetzt. AmbientCapabilities= Steuert, welche Capabilities in der Umgebungs-Capability-Menge fur den ausgefuhrten Prozess aufgenommen werden. Akzeptiert eine Leerzeichen-getrennte Liste von Capability-Namen, z.B. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. Diese Option kann mehr als einmal auftauchen, die Umgebungsmengen werden zusammengefuhrt (siehe Beispiele oben in CapabilityBoundingSet=). Falls der Liste von Capabilities >>~<< vorangestellt wird, werden alle bis auf die aufgefuhrten Capabilities aufgenommen, die Wirkung der Zuweisung invertiert. Falls die leere Zeichenkette dieser Option zugewiesen wird, wird die Umgebungsmenge auf die leere Capability-Menge zuruckgesetzt und alle vorhergehenden Einstellungen haben keine Wirkung. Falls auf >>~<< (ohne weiteres Argument) gesetzt, wird die Umgebungsmenge auf die komplette Menge der verfugbaren Capabilities zuruckgesetzt und alle vorhergehenden Einstellungen zuruckgenommen. Beachten Sie, dass die Hinzunahme von Capabilities in die Umgebungsmenge sie auch zu der vererbbaren Menge des Prozesses hinzufugt. Umgebungs-Capabilitymengen sind nutzlich, falls Sie einen Prozess als nicht privilegierter Benutzer ausfuhren wollen, ihm aber dennoch einige Capabilities geben mochten. Beachten Sie, dass in diesem Fall die Option keep-caps automatisch zu SecureBits= hinzugefugt wird, um die Capabilities uber den Benutzerwechsel hinweg zu erhalten. AmbientCapabilities= betrifft keine Befehle, denen >>+<< vorangestellt ist. Hinzugefugt in Version 229. SICHERHEIT NoNewPrivileges= Akzeptiert ein logisches Argument. Falls wahr, wird sichergestellt, dass der Diensteprozess und samtliche seiner Kindprozesse niemals mittels execve() neue Privilegien erlangen konnen (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 erhohen konnen. Standardmassig falsch. Auf jeden Fall wird der Dienst in einem neuen Einhangenamensraum und deaktiviertem SELinux ausgefuhrt, und alle Dateisysteme werden mit dem Schalter MS_NOSUID eingehangt. Siehe auch Schalter >>Keine neuen Privilegien<<[4]. Beachten Sie, dass diese Einstellung nur Auswirkungen auf die Prozesse der Unit selbst hat (oder alle anderen Prozesse, die direkt oder indirekt von ihnen per Fork erzeugt wurden). Sie hat keine Auswirkung auf Prozesse, die moglicherweise auf Anforderungen von ihnen mittels Werkzeugen wie at(1), crontab(1), systemd-run(1) oder beliebigen IPC-Diensten erzeugt wurden. Hinzugefugt in Version 187. SecureBits= Steuert die Menge der sicheren Bits fur den ausgefuhrten Prozess. Akzeptiert eine durch Leerzeichen getrennte Kombination von Optionen aus der folgenden Liste: keep-caps, keep-caps-locked, no-setuid-fixup, no-setuid-fixup-locked, noroot und noroot-locked. Diese Option darf mehr als einmal auftauchen, dann werden die sicheren Bits ODER-verknupft. Falls der Option die leere Zeichenkette zugewiesen wird, werden die Bits auf 0 zuruckgesetzt. Dies betrift keine Befehle, denen >>+<< vorangestellt ist. Siehe capabilities(7) fur Details. MANDATORY ACCESS CONTROL (VERFPLICHTENDE ZUGRIFFSSTEUERUNG) Diese Optionen sind nur fur Systemdienste verfugbar und werden nicht fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstutzt. SELinuxContext= Setzt den SELinux-Sicherheitskontext des ausgefuhrten Prozesses. Falls gesetzt, wird dies den automatischen Domain-Ubergang ausser Kraft setzen. Allerdings muss die Policy den Ubergang erlauben. Diese Anweisung wird ignoriert, falls SELinux deaktiviert ist. Falls >>-<< vorangestellt ist, wird ein Fehlschlag, den SELinux-Sicherheitskontext zu setzen, ignoriert; es ist aber weiterhin moglich, dass nachfolgende execve() fehlschlagen, falls die Richtlinie keine Uberleitung fur die nicht ausser Kraft gesetzten Kontexte erlaubt. Dies betrifft keine Befehle, denen >>+<< vorangestellt ist. Siehe setexeccon(3) fur Details. Hinzugefugt in Version 209. AppArmorProfile= Akzeptiert einen Profilnamen als Argument. Der von der Unit ausgefuhrte Prozess wird beim Start in dieses Profil umschalten. Profile mussen bereits in den Kernel geladen sein oder die Unit schlagt fehl. Falls ein >>-<< vorangestellt ist, werden alle Fehler ignoriert. Diese Einstellung hat keine Auswirkung, falls AppArmor nicht aktiviert ist. Diese Einstellung betrifft keine Befehle, denen >>+<< vorangestellt ist. Hinzugefugt in Version 210. SmackProcessLabel= Akzeptiert ein SMACK64-Sicherheits-Label als Argument. Der durch diese Unit ausgefuhrte Prozess wird unter diesem Label gestartet und SMACK wird darauf basierend entscheiden, ob die Ausfuhrung des Prozesses erlaubt ist. Der Prozess wird weiter unter dem hier angegebenen Label laufen, ausser falls das Programm seinen eigenen SMACK64EXEC-Label hat, in welchem Falle der Prozess dazu ubergehen wird, unter diesem Label zu laufen. Falls nicht angegeben, wird der Label verwandt, unter dem Systemd lauft. Diese Anweisung wird ignoriert, falls SMACK deaktiviert ist. Diesem Wert kann >>-<< vorangestellt werden, wodurch alle Fehler ignoriert werden. Ein leerer Wert kann angegeben werden, um alle vorhergehenden Zuweisungen zuruckzusetzen. Dies betrifft keine Befehle, denen >>+<< vorangestellt ist. Hinzugefugt in Version 218. PROZESSEIGENSCHAFTEN LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, LimitRTTIME= Setzt die weichen und harten Beschrankungen fur verschiedene Ressourcen fur ausgefuhrte Prozesse. Siehe setrlimit(2) fur Details uber das Prozessressourcen-Begrenzungskonzept. Prozessressourcenbegrenzungen konnen in zwei Formaten festgelegt werden: entweder als einzelner Wert, um eine bestimmte weiche und harte Begrenzung auf den gleichen Wert zu setzen, oder als Doppelpunkt-getrenntes Paar weich:hart, um beide Begrenzungen individuell zu setzen (z.B. >>LimitAS=4G:16G<<). Verwenden Sie die Zeichenkette infinity, um keine Begrenzung fur eine bestimmte Ressource zu konfigurieren. Die multiplikativen Endungen K, M, G, T, P und E (auf Basis 1024) konnen fur Ressourcenbegrenzungen, die in Bytes gemessen werden, verwandt werden (z.B. >>LimitAS=16G<<). Fur Begrenzungen, die sich auf Zeitwerte beziehen, konnen die im Englischen normalen Zeiteinheiten ms, s, min, h und so weiter verwandt werden (siehe systemd.time(7) fur Details). Beachten Sie, dass die Standardzeiteinheit als Sekunden impliziert ist, falls keine Zeiteinheit fur LimitCPU= angegeben ist. Fur LimitRTTIME= wird als Standardeinheit Mikrosekunden impliziert. Beachten Sie, dass die effektive Granularitat der Begrenzungen ihre Durchsetzung beeinflussen konnte. Beispielsweise werden fur LimitCPU= festgelegte Zeitbeschrankungen implizit auf Vielfache von 1s aufgerundet. Fur LimitNICE= kann der Wert in zwei Syntaxen festgelegt werden: falls ihm >>+<< oder >>-<< vorangestellt wird, wird der Wert als regularer Linux-Nice-Wert im Bereich -2019 interpretiert. Falls ihm so etwas nicht vorangestellt wird, wird der Wert als roher Ressourcenbegrenzungsparameter im Bereich 040 (wobei 0 aquivalent zu 1 ist) verstanden. Beachten Sie, dass die meisten der mit diesen Optionen konfigurierten Ressourcenbeschrankungen prozessbezogen sind. Prozesse konnen einen Fork durchfuhren, um einen neuen Satz an Ressourcen zu erlangen. Diese neuen Ressourcen konnen unabhangig vom ursprunglichen Prozess verbucht werden und daher gesetzten Beschrankungen entkommen.Beachten Sie auch, dass LimitRSS= unter Linux nicht implementiert ist und das Setzen keinen Effekt hat. Oft ist es ratsam, die in systemd.resource-control(5) aufgefuhrten Ressourcensteuerungen gegenuber den prozessabhangigen zu bevorzugen, da sie, auf Dienste als ganzes angewandt, zur Laufzeit verandert werden und im Allgemeinen ausdrucksstarker sind. Beispielsweise ist MemoryMax= ein leistungsfahigerer (und funktionierender) Ersatz fur LimitRSS=. Beachten Sie, dass LimitNPROC= die Anzahl der Prozesse einer (echten) UID begrenzen wird und nicht die Anzahl der vom Dienst (mit Fork) gestarteten Prozesse. Daher ist diese Begrenzung fur alle unter der gleichen UID laufenden Prozesse kumulierend. Bitte beachten Sie auch, dass LimitNPROC= nicht durchgesetzt wird, falls der Dienst als root lauft (und seine Privilegien nicht abgibt). Aufgrund dieser Einschrankungen ist TasksMax= (siehe systemd.resource-control(5)) typischerweise eine bessere Wahl als LimitNPROC=. Nicht explizit konfigurierte Ressourcenbeschrankungen fur eine Unit verwenden als Vorgabe die in den verschiedenen in systemd-system.conf(5) verfugbaren Optionen DefaultLimitCPU=, DefaultLimitFSIZE=, konfigurierten Werte und - falls sie dort nicht konfiguriert sind - die Kernel- oder benutzerbezogenen Vorgaben, wie sie durch das Betriebssystem (Letzteres nur fur Benutzerdienste, siehe unten) definiert sind. Fur System-Units konnen diese Ressourcenbeschrankungen frei gewahlt werden. Wenn diese Einstellungen in einem Benutzerdienst (d.h. einem Dienst, der von der benutzerbezogenen Instanz des Diensteverwalters ausgefuhrt wird) konfiguriert sind, konnen sie nicht zum Anheben der Beschrankungen uber die Werte, die fur den Benutzerverwalter beim ersten Aufruf selbst gesetzt sind, verwandt werden, da dem Benutzerverwalter im Allgemeinen hierfur die Privilegien fehlen. Im Benutzerkontext sind diese Konfigurationsoptionen daher nur nutzlich, um die hereingegebenen Beschrankungen zu senken oder fur den Benutzer konfigurierten weichen Beschrankungen maximal auf die harten Beschrankungen anzuheben. Um die Benutzerbeschrankungen weiter anzuheben, unterscheiden sich die verfugbaren Konfigurationsmechanismen zwischen Betriebssystemen, benotigen aber typischerweise Privilegien. In den meisten Fallen ist es moglich, hohere benutzerbezogene Ressourcenbeschrankungen mittels PAM zu konfigurieren oder durch Setzen von Beschrankungen auf den System-Dienst, der den Diensteverwalter des Benutzers einkapselt, d.h. der Instanz von user@.service des Benutzers. Starten Sie den Diensteverwalter des Benutzers neu, nachdem Sie solche Anderungen vorgenommen haben. Tabelle 1. Ressourcenbegrenzungsanweisungen, ihre aquivalenten Ulimit-Shell-Befehle und die verwandte Einheit +-----------------+---------------------+---------------------+------------------------------+ |Anweisung | ulimit-Aquivalent | Einheit | Hinweise | +-----------------+---------------------+---------------------+------------------------------+ |LimitCPU= | ulimit -t | Sekunden | - | +-----------------+---------------------+---------------------+------------------------------+ |LimitFSIZE= | ulimit -f | Bytes | - | +-----------------+---------------------+---------------------+------------------------------+ |LimitDATA= | ulimit -d | Bytes | Nicht verwenden. Diese | | | | | beschrankt den erlaubten | | | | | Adressbereich, nicht die | | | | | Speicherverwendung! | | | | | Standardmassig unbeschrankt | | | | | und sollte nicht gesenkt | | | | | werden. Um die | | | | | Speicherverwendung zu | | | | | beschranken, siehe | | | | | MemoryMax= in | | | | | systemd.resource-control(5). | +-----------------+---------------------+---------------------+------------------------------+ |LimitSTACK= | ulimit -s | Bytes | - | +-----------------+---------------------+---------------------+------------------------------+ |LimitCORE= | ulimit -c | Bytes | - | +-----------------+---------------------+---------------------+------------------------------+ |LimitRSS= | ulimit -m | Bytes | Nicht verwenden. Hat unter | | | | | Linux keine Auswirkung. | +-----------------+---------------------+---------------------+------------------------------+ |LimitNOFILE= | ulimit -n | Anzahl an | Nicht verwenden. Seien Sie | | | | Dateideskriptoren | beim Anheben der weichen | | | | | Begrenzung uber 1024 | | | | | vorsichtig, da unter Linux | | | | | select(2) nicht mit | | | | | Dateideskriptoren uber 1023 | | | | | umgehen kann. Heutzutage ist | | | | | die harte Begrenzung 524288. | | | | | Verglichen mit historischen | | | | | Vorgaben ist dies ein sehr | | | | | hoher Wert. Typische | | | | | Anwendungen sollten ihre | | | | | weiche Begrenzung | | | | | selbstandig auf die harte | | | | | Begrenzung anheben, falls | | | | | sie mit Dateideskriptoren | | | | | oberhalb von 1023 umgehen | | | | | konnen, d.h. nicht select(2) | | | | | verwenden. Beachten Sie, | | | | | dass Dateideskriptoren | | | | | heutzutage wie jede andere | | | | | Form an Speicher verwaltet | | | | | werden und es daher keinen | | | | | Bedarf zum Absenken der | | | | | harten Begrenzung geben | | | | | sollte. Verwenden Sie | | | | | MemoryMax=, um die | | | | | Gesamtspeicherverwendung von | | | | | Diensten zu steuern, | | | | | einschliesslich des | | | | | Speichers fur | | | | | Dateideskriptoren. | +-----------------+---------------------+---------------------+------------------------------+ |LimitAS= | ulimit -v | Bytes | Nicht verwenden. Diese | | | | | beschrankt den erlaubten | | | | | Adressbereich, nicht die | | | | | Speicherverwendung! | | | | | Standardmassig unbeschrankt | | | | | und sollte nicht gesenkt | | | | | werden. Um die | | | | | Speicherverwendung zu | | | | | beschranken, siehe | | | | | MemoryMax= in | | | | | systemd.resource-control(5). | +-----------------+---------------------+---------------------+------------------------------+ |LimitNPROC= | ulimit -u | Anzahl an Prozessen | Diese Beschrankung wird | | | | | basierend auf der Anzahl der | | | | | dem Benutzer gehorenden | | | | | Prozesse durchgesetzt. | | | | | Normalerweise ist es besser, | | | | | die Prozesse pro Dienst | | | | | nachzuverfolgen, d.h. | | | | | Verwendung von TasksMax=, | | | | | siehe | | | | | systemd.resource-control(5). | +-----------------+---------------------+---------------------+------------------------------+ |LimitMEMLOCK= | ulimit -l | Bytes | - | +-----------------+---------------------+---------------------+------------------------------+ |LimitLOCKS= | ulimit -x | Anzahl an Sperren | - | +-----------------+---------------------+---------------------+------------------------------+ |LimitSIGPENDING= | ulimit -i | Anzahl von Signalen | - | | | | in der | | | | | Warteschlange | | +-----------------+---------------------+---------------------+------------------------------+ |LimitMSGQUEUE= | ulimit -q | Bytes | - | +-----------------+---------------------+---------------------+------------------------------+ |LimitNICE= | ulimit -e | Nice-Stufe | - | +-----------------+---------------------+---------------------+------------------------------+ |LimitRTPRIO= | ulimit -r | Echtzeitprioritat | - | +-----------------+---------------------+---------------------+------------------------------+ |LimitRTTIME= | ulimit -R | Mikrosekunden | - | +-----------------+---------------------+---------------------+------------------------------+ UMask= Steuert die Dateimoduserstellungsmaske. Akzeptiert einen Zugriffsmodus in oktaler Notation. Siehe umask(2) fur Details. Standardmassig 0022 fur System-Units. Fur Benutzer-Units wird der Vorgabewert von dem benutzerbezogenen Diensteverwalter geerbt (dessen Vorgabewert wiederum vom Systemdiensteverwalter geerbt wird, und daher typischerweise auch 0022 ist -- ausser dies wurde von einem PAM-Modul ausser Kraft gesetzt). Um die benutzerbezogene Maske fur alle Benutzerdienste zu andern, sollten Sie stattdessen die Einstellung UMask= in der Systemdiensteinstanz user@.service des Benutzers setzen. Die benutzerbezogene Umask kann auch mittels des Feldes umask in dem JSON-Benutzerdatensatz[5] eines Benutzers gesetzt werden (fur Benutzer, die mittels systemd-homed.service(8) verwaltet werden, kann dieses Feld auch uber homectl --umask= gesteuert werden). Es kann auch mittels eines PAM-Moduls wie pam_umask(8) gesetzt werden. CoredumpFilter= Steuert, welche Arten von Speicher-Mappings gesichert werden, falls der Prozess einen Speicherauszug durchfuhrt (mittels der Datei /proc/PID/coredump_filter). Akzeptiert eine Leerraum-getrennte Kombination von Mapping-Typnamen oder -nummern (mit der Vorgabebasis 16). Mapping-Typ-Namen sind private-anonymous, shared-anonymous, private-file-backed, shared-file-backed, elf-headers, private-huge, shared-huge, private-dax, shared-dax und der besondere Wert all (alle Typen) und default (die Vorgabe des Kernels >>private-anonymous shared-anonymous elf-headers private-huge<<). Siehe core(5) fur die Bedeutung der Mapping-Typen. Falls mehrfach angegeben, werden alle angegebenen Masken mit ODER verbunden. Wenn nicht gesetzt oder der leere Wert zugewiesen wurde, wird der ererbte Wert nicht geandert. Beispiel 2. DAX-Seiten zum Speicherauszugsfilter hinzufugen CoredumpFilter=default private-dax shared-dax Hinzugefugt in Version 246. KeyringMode= Steuert, wie der Kernelsitzungsschlusselbund fur den Dienst eingerichtet wird (siehe session-keyring(7) fur Details uber den Sitzungsschlusselbund). Akzeptiert einen aus inherit, private, shared. Falls auf inherit gesetzt, wird keine besondere Schlusselbundeinrichtung vorgenommen und das Standardverhalten des Kernels wird angewandt. Falls private verwandt wird, wird ein neuer Sitzungsschlusselbund bereitgestellt, wenn ein Diensteprozess aufgerufen wird und dieser nicht mit einem Benutzerschlusselbund verbunden ist. Dies ist die fur Systemdienste empfohlene Einstellung, da sie sicherstellt, dass mehrere Dienste, die unter der gleichen Systembenutzerkennung laufen (insbesondere des Benutzers root) ihr Schlusselmaterial nicht gemeinsam benutzen. Falls shared verwandt wird, wird ein neuer Schlusselbund wie fur private reserviert, aber der Benutzerschlusselbund des mit User= konfigurierten Benutzers wird mit eingebunden, so dass die dem Benutzer zugeordneten Schlussel von den Prozessen der Unit angefragt werden konnen. In diesem Modus konnen mehrere Units, die Prozesse unter der selben Benutzerkennung ausfuhren, Schlusselmaterial gemeinsam benutzen. Ausser bei der Auswahl von inherit wird die eindeutige Aufrufkennung fur die Unit (siehe unten) als geschutzter Schlussel unter dem Namen >>invocation_id<< zu dem neu erstellten Sitzungsschlusselbund hinzugefugt. Standardmassig private fur Dienste des Systemdiensteverwalters und inherit fur nicht Dienste-Units und fur Dienste des Benutzerdiensteverwalters. Hinzugefugt in Version 235. OOMScoreAdjust= Setzt den Anpassungswert fur die Speicherknappheit- (OOM-)Killer-Bewertung des Kernels fur ausgefuhrte Prozesse. Akzeptiert eine Ganzzahl zwischen -1000 (um das OOM-Toten von Prozessen dieser Unit zu deaktivieren) und 1000 (womit das Toten von Prozessen dieser Unit bei Speicherdruck sehr wahrscheinlich wird). Siehe Das /proc-Dateisystem[6] fur Details. Falls nicht angegeben, ist die Vorgabe die OOM-Bewertungsanpassungsstufe des Diensteverwalters selbst, die normalerweise auf 0 gesetzt ist. Verwenden Sie die Einstellung OOMPolicy= von Dienste-Units, um zu konfigurieren, wie der Diensteverwalter darauf reagieren soll, wenn der OOM-Killer oder systemd-oomd einen Prozess des Dienstes beendet. Siehe systemd.service(5) fur Details. TimerSlackNSec= Setzt den Timer-Spielraum in Nanosekunden fur den ausgefuhrten Prozess). Der Timer-Spielraum steuert die Genauigkeit der durch Systemd-Timer ausgelosten Aufwachaktionen. Siehe prctl(2) fur weitere Informationen. Beachten Sie, dass im Gegensatz zu den meisten anderen Zeitdauerdefinitionen dieser Parameter einen Ganzzahlwert in Nanosekunden akzeptiert, falls keine Einheit angegeben ist. Es werden auch die normalen Zeiteinheiten verstanden. Personality= Steuert, welche Kernelarchitektur uname(2) melden soll, wenn es von Unit-Prozessen aufgerufen wird. Akzeptiert eine der Architekturkennungen arm64, arm64-be, arm, arm-be, x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, s390 oder s390x. Welche Personalitatsarchitekturen unterstutzt werden, hangt von der nativen Architektur des Kernels ab. Normalerweise unterstutzen die 64-Bit-Versionen der verschiedenen Systemarchitekturen die direkte Entsprechung der 32-Bit-Personalitatsarchitektur, aber keine anderen. Beispielsweise unterstutzen x86-64-Systeme die x86-64- und x86-Personalitaten, aber keine anderen. Die Personalitatsfunktionalitat ist nutzlich, wenn 32-Bit-Dienste auf einem 64-Bit-System ausgefuhrt werden. Falls nicht angegeben, wird die Personalitat nicht verandert und spiegelt daher die Personalitat des Systemkernels wider. Diese Option ist auf Architekturen nicht nutzlich, fur die nur eine native Wortbreite jemals verfugbar war, wie m68k (nur 32 bit) oder alpha (nur 64 bit). Hinzugefugt in Version 209. IgnoreSIGPIPE= Akzeptiert ein logisches Argument. Falls wahr, wird SIGPIPE in dem ausgefuhrten Prozess ignoriert. Standardmassig wahr, da SIGPIPE im Allgemeinen nur in Shell-Pipes nutzlich ist. SCHEDULING Nice= Setzt den Vorgabe-Nice-Wert (Scheduling-Prioritat) fur ausgefuhrte Prozesse. Akzeptiert eine Ganzzahl zwischen -20 (hochste Prioritat) und 19 (niedrigste Prioritat). Im Falle von Ressourcenkonflikten bedeuten kleinere Werte, dass mehr Ressourcen fur die Prozesse der Unit zur Verfugung gestellt werden und grossere Werte, dass weniger Ressourcen zur Verfugung gestellt werden. Siehe setpriority(2) fur Details. CPUSchedulingPolicy= Setzt die CPU-Scheduling-Richtlinie fur ausgefuhrte Prozesse. Akzeptiert eines aus other, batch, idle, fifo, rr. Siehe sched_setscheduler(2) fur Details. CPUSchedulingPriority= Setzt die CPU-Scheduling-Prioritat fur ausgefuhrte Prozesse. Der verfugbare Prioritatenbereich hangt von der ausgewahlten CPU-Scheduling-Richtlinie (siehe oben) ab. Fur Echtzeit-Scheduling-Richtlinien kann eine Ganzzahl zwischen 1 (niedrigste Prioritat) und 99 (hochste Prioritat) verwandt werden. Im Falle von CPU-Ressourcenkonflikten bedeuten kleinere Werte, dass weniger CPU-Zeit dem Dienst zur Verfugung gestellt wird und grossere Werte bedeuten mehr. Siehe sched_setscheduler(2) fur Details. CPUSchedulingResetOnFork= Akzeptiert ein logisches Argument. Falls wahr, werden erhohte CPU-Scheduling-Prioritaten und -Richtlinien zuruckgesetzt, wenn ausgefuhrte Prozesse fork(2) aufrufen und konnen daher nicht an Kindprozesse durchsickern. Siehe sched_setscheduler(2) fur Details. Standardmassig falsch. CPUAffinity= Steuert die CPU-Affinitat des ausgefuhrten Prozesses. Akzeptiert eine durch Leerraum oder Kommata getrennte Liste von CPU-Indizes oder -Bereichen. Alternativ wird der besondere Wert >>numa<< akzeptiert. In diesem Fall leitet Systemd die erlaubten CPU-Bereiche basierend auf der Option NUMAMask= automatisch ab. 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-Affinitatsmasken zusammengefuhrt. Falls die leere Zeichenkette zugewiesen wird, wird die Maske zuruckgesetzt und alle vorherigen Zuweisungen haben keinen Effekt. Siehe sched_setaffinity(2) fur Details. NUMAPolicy= Steuert die NUMA-Speicherrichtlinie des ausgefuhrten Prozesses. Akzeptiert einen Richtlinientyp, einer aus: default, preferred, bind, interleave und local. Eine Liste von NUMA-Knoten, die der Richtlinie zugeordnet werden sollen, muss in NUMAMask= festgelegt werden. Fur weitere Details uber jede Richtlinie lesen Sie bitte set_mempolicy(2). Fur einen allgemeinen Uberblick uber die NUMA-Unterstutzung in Linux, siehe numa(7). Hinzugefugt in Version 243. NUMAMask= Steuert die NUMA-Knotenliste, die zusammen mit der ausgewahlten NUMA-Richtlinie angewandt wird. Akzeptiert eine Liste von NUMA-Knoten und hat die gleiche Syntax wie eine Liste von CPUs fur die Option CPUAffinity= oder den besonderen Wert >>all<<, der alle verfugbaren NUMA-Knoten in der Maske enthalt. Beachten Sie, dass fur die Richtlinien default und local keine Liste von NUMA-Knoten benotigt und fur die Richtlinie preferred ein einzelner NUMA-Knoten erwartet wird. Hinzugefugt in Version 243. IOSchedulingClass= Setzt die E/A-Scheduling-Klasse fur ausgefuhrte Prozesse. Akzeptiert eine der Zeichenketten realtime, best-effort oder idle. Die Vorgabe-Scheduling-Klasse des Kernels ist best-effort mit Prioritat 4. Falls dieser Option die leere Zeichenkette zugewiesen wird, haben alle vorhergehenden Zuweisungen zu IOSchedulingClass= und IOSchedulingPriority= keinen Effekt. Siehe ioprio_set(2) fur Details. IOSchedulingPriority= Setzt die E/A-Scheduling-Prioritat fur ausgefuhrte Prozesse. Akzeptiert eine Ganzzahl zwischen 0 (hochste Prioritat) und 7 (niedrigste Prioritat). Im Falle von E/A-Konflikten bedeuten kleinere Werte, dass den Prozessen der Unit mehr E/A-Bandbreite zur Verfugung gestellt wird und grossere Werte bedeuten weniger Bandbreite. Die verfugbaren Prioritaten hangen von der ausgewahlten E/A-Scheduling-Klasse (siehe oben) ab. Falls dieser Option die leere Zeichenkette zugewiesen wird, haben alle vorhergehenden Zuweisungen zu IOSchedulingClass= und IOSchedulingPriority= keinen Effekt. Fur die Vorgabe-Scheduling-Klasse des Kernels (best-effort) ist dies standardmassig 4. Siehe ioprio_set(2) fur Details. SANDBOXING Die nachfolgenden Sandboxing-Optionen bieten eine wirksame Art, die Kontakte des Systems im Hinblick auf die Prozesse der Unit zu begrenzen. Es wird empfohlen, so viele dieser Optionen wie moglich, ohne die Betriebsfahigkeit der Prozesse der Unit negativ zu betreffen, einzuschalten. Beachten Sie, dass viele dieser Sandboxing-Funktionalitaten beschwerdefrei auf Systemen, auf denen der unterliegende Sicherheitsmechanismus nicht verfugbar ist, ausgeschaltet werden. Beispielsweise hat ProtectSystem= keine Wirkung, falls der Kernel ohne Namensraume fur Dateisysteme gebaut wurde oder falls der Diensteverwalter in einem Container-Verwalter ausgefuhrt wird, der dafur sorgt, dass Dateisystem-Namensraume fur seine Nutzlast nicht verfugbar sind. Ahnlich hat RestrictRealtime= auf Systemen keine Wirkung, denen die Unterstutzung fur SECCOMP-Systemaufruffilterung fehlt oder in Containern, in denen die Unterstutzung dafur abgeschaltet ist. Beachten Sie auch, dass einige Sandboxing-Funktionalitat im Allgemeinen in Benutzerdiensten (d.h. Diensten, die vom benutzerbezogenen Diensteverwalter ausgefuhrt werden) nicht verfugbar ist. Insbesondere die verschiedenen Einstellungen, die die Unterstutzung fur Dateisystem-Namensraume benotigen (wie ProtectSystem=) sind nicht verfugbar, da die zugrundeliegende Kernelfunktionalitat nur fur privilegierte Prozesse erreichbar ist. Allerdings werden die meisten Namensraum-Einstellungen, die nicht in ihrem eigenen Benutzerdienst funktionieren, bei der Verwendung zusammen mit PrivateUsers=true funktionieren. Beachten Sie, dass verschiedene Optionen, die Verzeichnisse nur lesbar machen (wie ProtectSystem=, ReadOnlyPaths=, ) keine Auswirkung auf die Fahigkeit von Programmen haben, sich mit AF_UNIX-Sockets in diesen Verzeichnissen zu verbinden. Daher konnen diese Optionen nicht zum Begrenzen von Zugriff auf IPC-Dienste verwandt werden. ProtectSystem= Akzeptiert ein logisches Argument oder die besonderen Werte >>full<< oder >>strict<<. Falls wahr, werden die Verzeichnisse /usr/ und die des Systemstartprogramms (/boot and /efi) fur von dieser Unit aufgerufene Prozesse nur lesbar eingehangt. Falls auf >>full<< gesetzt, wird auch das Verzeichnis /etc/ nur lesbar eingehangt. Falls auf >>strict<< gesetzt, wird die gesamte Dateisystemhierarchie nur lesbar eingehangt, ausser der API-Dateisystemunterbaume /dev/, /proc/ und /sys/ (schutzen Sie diese Verzeichnisse mittels PrivateDevices=, ProtectKernelTunables=, ProtectControlGroups=). Diese Einstellung stellt sicher, dass alle Anderungen an dem vom Lieferanten bereitgestellten Betriebssystem (und optional seiner Konfiguration und lokaler Einhangungen) fur den Dienst verboten sind. Es wird empfohlen, diese Einstellung fur alle langlaufenden Dienste zu aktivieren, ausser sie sind an Systemaktualisierungen beteiligt oder mussen das Betriebssystem auf eine andere Art verandern. Falls diese Option verwandt wird, kann ReadWritePaths= verwandt werden, um bestimmte Verzeichnisse von dem nur lesbaren Verhalten auszunehmen. Ahnlich schliessen StateDirectory=, LogsDirectory= und zugehorige Verzeichniseinstellungen (siehe unten) die konkreten Verzeichnisse von der Wirkung von ProtectSystem= aus. Diese Einstellung ist impliziert, falls DynamicUser= gesetzt ist. Diese Einstellung kann nicht fur alle Falle den Schutz sicherstellen. Im Allgemeinen hat es die gleichen Begrenzungen wie ReadOnlyPaths=, siehe unten. Standardmassig aus. Hinzugefugt in Version 214. ProtectHome= Akzeptiert ein logisches Argument oder die besonderen Werte >>read-only<< oder >>tmpfs<<. Falls wahr, wird der Zugriff auf die Verzeichnisse /home/, /root und /run/user entzogen, sie erscheinen fur von der Unit aufgerufene Prozesse leer. Falls auf >>read-only<< gesetzt, werden die drei Verzeichnisse stattdessen nur lesbar gesetzt. Falls auf >>tmpfs<< gesetzt, werden temporare Dateisysteme auf diesen drei Verzeichnissen im nur-lesbaren Modus eingehangt. Der Wert >>tmpfs<< ist nutzlich, um Home-Verzeichnisse, die fur die von der Unit aufgerufenen Prozesse nicht relevant sind, zu verstecken, wahrend gleichzeitig notwendige Verzeichnisse weiterhin sichtbar gemacht werden konnen, indem sie mit BindPaths= oder BindReadOnlyPaths= aufgelistet werden. Setzen dieser Einstellung auf >>yes<< ist fast aquivalent zum Setzen der drei Verzeichnisse in InaccessiblePaths=. Ahnlich ist >>read-only<< fast aquivalent zu ReadOnlyPaths= und >>tmpfs<< ist fast aquivalent zu TemporaryFileSystem= mit >>:ro<<. Es wird empfohlen, diese Einstellung fur alle langlaufenden Dienste (insbesondere solchen zu Netzen) zu aktivieren, um sicherzustellen, dass sie keinen Zugriff auf private Benutzerdaten bekommen, ausser der Dienst benotigt tatsachlich Zugriff auf die privaten Daten der Benutzer. Diese Einstellung ist impliziert, falls DynamicUser= gesetzt ist. Diese Einstellung kann nicht fur alle Falle den Schutz sicherstellen. Im Allgemeinen hat es die gleichen Begrenzungen wie ReadOnlyPaths=, siehe unten. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 214. RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= Diese Optionen akzeptieren eine Leerraum-getrennte Liste von Verzeichnisnamen. Die angegebenen Verzeichnisnamen mussen relativ sein und durfen >>..<< nicht enthalten. Falls beim Starten der Unit gesetzt, werden ein oder mehrere Verzeichniss(e) mit den angegebenen Namen unterhalb der in der nachfolgenden Tabelle definierten Orte erstellt (einschliesslich ihrer Eltern), wenn die Unit gestartet wird. Auch wird die entsprechende Umgebungsvariable mit dem vollstandigen Pfad der Verzeichnisse definiert. Falls mehrere Verzeichnisse gesetzt sind, dann werden die Pfade in der Umgebungsvariablen mit dem Doppelpunkt (>>:<<) verkettet. Tabelle 2. Automatische Verzeichniserstellung und Umgebungsvariablen +------------------------+---------------+----------------------+--------------------------+ |Verzeichnis | Unterhalb vom | Unterhalb vom Pfad | Umgebungsvariablenmenge | | | Pfad von | von Benutzer-Units | | | | System-Units | | | +------------------------+---------------+----------------------+--------------------------+ |RuntimeDirectory= | /run/ | $XDG_RUNTIME_DIR | $RUNTIME_DIRECTORY | +------------------------+---------------+----------------------+--------------------------+ |StateDirectory= | /var/lib/ | $XDG_STATE_HOME | $STATE_DIRECTORY | +------------------------+---------------+----------------------+--------------------------+ |CacheDirectory= | /var/cache/ | $XDG_CACHE_HOME | $CACHE_DIRECTORY | +------------------------+---------------+----------------------+--------------------------+ |LogsDirectory= | /var/log/ | $XDG_STATE_HOME/log/ | $LOGS_DIRECTORY | +------------------------+---------------+----------------------+--------------------------+ |ConfigurationDirectory= | /etc/ | $XDG_CONFIG_HOME | $CONFIGURATION_DIRECTORY | +------------------------+---------------+----------------------+--------------------------+ Im Falle von RuntimeDirectory= werden die innersten Unterverzeichnisse entfernt, wenn die Unit gestoppt wird. Es ist moglich, in diesem Fall die festgelegten Verzeichnisse zu erhalten, falls RuntimeDirectoryPreserve= auf restart oder yes konfiguriert ist (siehe unten). Die mit StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= festgelegten Verzeichnisse werden nicht entfernt, wenn die Unit gestoppt wird. Ausser im Fall von ConfigurationDirectory= werden die innersten festgelegten Verzeichnisse dem in User= und Group= angegebenem Benutzer und der Gruppe gehoren. Falls die angegebenen Verzeichnisse bereits existieren und ihre besitzenden Benutzer und Gruppe nicht auf die konfigurierten passen, werden alle Dateien und Verzeichnisse unterhalb der angegebenen Verzeichnisse sowie alle Verzeichnisse selbst rekursiv geandert, so dass die Eigentumerschaft auf die konfigurierte passt. Falls die angegebenen Verzeichnisse bereits dem richtigen Benutzer und der richtigen Gruppe gehoren, werden als Optimierung alle Dateien und Verzeichnisse darunter unverandert gelassen, selbst falls sie nicht auf das angeforderte passen. Die Zugriffsmodi der innersten angegebenen Verzeichnisse wird auf das, was in RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= und ConfigurationDirectoryMode= festgelegt ist, angepasst. Diese Optionen implizieren BindPaths= fur die festgelegten Pfade. Bei der Kombination mit RootDirectory= oder RootImage= werden diese Pfade immer innerhalb des Rechners liegen und von dort in den Dateisystemnamensraum der Unit eingehangt. Falls DynamicUser= verwandt wird, andert sich die Logik fur CacheDirectory=, LogsDirectory= und StateDirectory= leicht: die Verzeichnisse werden unterhalb /var/cache/private, /var/log/private bzw. /var/lib/private erstellt, die Verzeichnisse des Rechners sind, die fur nicht privilegierte Benutzer nicht zugreifbar sind. Dadurch wird sichergestellt, dass Zugriff auf diese Verzeichnisse nicht uber die Wiederverwendung dynamischer Benutzerkennungen moglich 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/cache, /var/log und /var/lib auf. Verwenden Sie RuntimeDirectory=, um eine oder mehrere Laufzeitverzeichnisse fur die Unit zu verwalten und ihre Lebensdauer an die Lebensdauer des Daemons zu koppeln. Dies ist insbesonders fur nicht privilegierte Daemons nutzlich, die aufgrund fehlender Privilegien keine Laufzeitverzeichnisse in /run/ erstellen konnen und um sicherzustellen, dass die Laufzeitverzeichnisse nach der Verwendung automatisch bereinigt werden. Fur Laufzeitverzeichnisse, die eine komplexere oder andere Konfiguration oder Lebensdauergarantie benotigen, prufen Sie den Einsatz von tmpfiles.d(5). RuntimeDirectory=, StateDirectory=, CacheDirectory= und LogsDirectory= unterstutzen optional einen zweiten Parameter, der durch >>:<< abgetrennt wird. Der zweite Parameter wird als Zielpfad interpretiert, der als Symlink auf das Verzeichnis erstellt wird. Die Symlinks werden erstellt, nachdem alle Optionen BindPaths= oder TemporaryFileSystem= eingerichtet wurden, um fluchtige Symlinks zu ermoglichen. Die gleiche Quelle kann mehrere Symlnks haben, indem der gleiche erste Parameter, aber ein verschiedener zweiter Parameter verwandt wird. Die durch diese Optionen definierten Verzeichnisse werden immer unter den von Systemd verwandten Standardpfaden (/var/, /run/, /etc/ ) erstellt. Falls der Dienst Verzeichnisse an einem anderen Ort benotigt, muss ein anderer Mechanismus zu deren Erstellung verwandt werden. tmpfiles.d(5) stellt Funktionalitat bereit, die sich mit diesen Optionen uberlappt. Es wird empfohlen, dass diese Optionen eingesetzt werden, da die Lebensdauer der Verzeichnisse an die Lebensdauer der Unit gekoppelt ist, und es nicht notwendig ist, sicherzustellen, dass die tmpfiles.d-Konfiguration vor dem Start der Unit ausgefuhrt wird. Um alle von diesen Einstellungen erzeugten Verzeichnisse zu entfernen, verwenden Sie den Befehl systemctl clean auf die relevanten Units, siehe systemctl(1) fur Details. Beispiel: Falls eine Systemdienste-Unit RuntimeDirectory=foo/bar baz enthalt, erstellt der Diensteverwalter /run/foo (falls es noch nicht existiert), /run/foo/bar und /run/baz. Die Verzeichnisse /run/foo/bar und /run/baz ausser /run/foo gehoren dem Benutzer und der Gruppe, die in User= und Group= angegeben sind und werden entfernt, wenn der Dienst gestoppt wird. Beispiel: Falls eine Systemdienste-Unit RuntimeDirectory=foo/bar StateDirectory=aaa/bbb ccc enthalt, dann wird die Umgebungsvariable >>RUNTIME_DIRECTORY<< mit >>/run/foo/bar<< und >>STATE_DIRECTORY<< mit >>/var/lib/aaa/bbb:/var/lib/ccc<< gesetzt. Beispiel: Falls eine Systemdienste-Unit RuntimeDirectory=foo:bar foo:baz Der Diensteverwalter erstellt /run/foo (falls es noch nicht existiert) und /run/bar sowie /run/baz als Symlinks auf /run/foo. Hinzugefugt in Version 211. RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode=, ConfigurationDirectoryMode= Legt die Zugriffsmodi der in RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory= bzw. ConfigurationDirectory= angegebenen Verzeichnisse in einer oktalen Zahl fest. Standardmassig 0755. Siehe >>Permissions<< in path_resolution(7) fur eine Diskussion uber die Benennung der Berechtigungs-Bits. Hinzugefugt in Version 234. RuntimeDirectoryPreserve= Akzeptiert ein logisches Argument oder restart. Falls auf die Vorgabe no gesetzt, werden die in RuntimeDirectory= festgelegten Verzeichnisse immer entfernt, wenn der Dienst beendet wird. Falls auf restart gesetzt, werden die Verzeichnisse erhalten, wenn der Dienst sowohl automatisch als auch manuell neu gestartet wird. Hier bedeutet der automatische Neustart die in Restart= festgelegte Aktion und manueller Neustart bedeutet die durch systemctl restart foo.service ausgeloste. Falls auf yes gesetzt, werden die Verzeichnisse nicht entfernt, wenn der Dienst beendet wird. Beachten Sie, dass die in RuntimeDirectory= festgelegten Verzeichnisse entfernt werden, wenn das System neu gestartet wird, da das Laufzeitverzeichnis /run/ ein >>tmpfs<<-Einhangepunkt ist. Hinzugefugt in Version 235. TimeoutCleanSec= Konfiguriert fur die mittels systemctl clean erbetene Aufraumaktion eine Zeituberschreitung, siehe systemctl(1) fur Details. Akzeptiert die gewohnlichen Zeitwerte und ist standardmassig infinity, d.h. standardmassig wird keine Zeituberschreitung angewandt. Falls eine Zeituberschreitung konfiguriert ist, wird die Aufraumaktion zwangsweise beendet, wenn die Zeituberschreitung erreicht ist, moglicherweise verbleiben dann Ressourcen auf der Platte. Hinzugefugt in Version 244. ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=, ExecPaths=, NoExecPaths= Richtet einen neuen Dateisystemnamensraum fur ausgefuhrte Prozesse ein. Diese Optionen konnen zur Begrenzung des Zugriffs eines Prozesses auf das Dateisystem verwandt werden. Jede Einstellung akzeptiert eine Leerzeichen-getrennte Liste von Pfaden, die relativ zum Wurzelverzeichnis des Rechners (d.h. des Systems, das den Diensteverwalter ausfuhrt) ist. Beachten Sie, dass die Pfade relativ zu dem mit RootDirectory=/RootImage= gesetzten Wurzelverzeichnis aufgelost werden, falls sie Symlinks enthalten. In ReadWritePaths= aufgefuhrte Pfade sind von innerhalb des Namensraums mit den gleichen Zugriffsmodi wie von ausserhalb zugreifbar. Auf in ReadOnlyPaths= aufgefuhrte Pfade kann nur lesend zugegriffen werden, Schreiben wird abgelehnt, selbst falls die normale Dateizugriffssteuerung dies erlauben wurde. Schachteln Sie ReadWritePaths= innerhalb von ReadOnlyPaths=, um schreibbare Unterverzeichnisse innerhalb nur lesbarer Verzeichnisse bereitzustellen. Verwenden Sie ReadWritePaths=, um bestimmte Pfade fur den Schreibzugriff freizuschalten, falls ProtectSystem=strict verwandt wird. Beachten Sie, dass ReadWritePaths= nicht zum Erlangen von Schreibzugriff auf ein Dateisystem verwandt werden kann, dessen Superblock schreibgeschutzt eingehangt ist. Unter Linux wird fur jeden Einhangepunkt der Schreibzugriff nur erlaubt, falls der Einhangepunkt selbst und der ihm zugrundeliegende Dateisystemsuperblock nicht als schreibgeschutzt markiert sind. ReadWritePaths= steuert nur ersteres und nicht letzteres, daher bleibt ein schreibgeschutzter Dateisystemsuperblock geschutzt. In InaccessiblePaths= aufgefuhrte Pfade, einschliesslich der Dateisystemhierarchie darunter, werden fur Prozesse innerhalb des Namensraums unzugreifbar gemacht. Dies konnte restriktiver als gewunscht sein, da es nicht moglich ist, darin ReadWritePaths=, ReadOnlyPaths=, BindPaths= oder BindReadOnlyPaths= zu verschachteln. Fur eine flexiblere Option siehe TemporaryFileSystem=. Inhalte in den in NoExecPaths= aufgefuhrten Pfaden konnen nicht ausgefuhrt werden, selbst falls die gewohnliche Zugriffskontrolle dies erlauben wurde. Verschachteln Sie ExecPaths= innerhalb von NoExecPaths=, um ausfuhrbaren Inhalt innerhalb nichtausfuhrbarer Verzeichnisse bereitzustellen. Es konnen auch Pfade, die keine Verzeichnisse sind, angegeben werden. Diese Optionen konnen mehr als einmal angegeben werden, dann haben alle aufgefuhrten Pfade von innerhalb des Namensraums aus beschrankten Zugriff. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste zuruckgesetzt und alle vorherigen Zuweisungen haben keinen Effekt. Pfaden in ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=, ExecPaths= und NoExecPaths= kann ein >>-<< vorangestellt werden, wodurch sie ignoriert werden, falls sie nicht existieren. Falls ihnen >>+<< vorangestellt wird, werden die Pfade als relativ zum Wurzelverzeichnis der Unit akzeptiert, wie dies mit RootDirectory=/RootImage= konfiguriert ist, statt relativ zum Wurzelverzeichnis des Rechners (siehe oben). Wenn Sie >>-<< und >>+<< auf dem gleichen Pfad kombinieren, verwenden Sie >>-<< zuerst und danach >>+<<. Beachten Sie, dass diese Einstellungen die Ausbreitung von Einhangungen von den Prozessen einer Unit zum Rechner abtrennt. Dies bedeutet, dass diese Einstellung nicht fur Dienste benutzt werden darf, die in der Lage sein mussen, Einhangepunkte im Haupteinhangenamensraum zu installieren. Die ReadWritePaths=- und ReadOnlyPaths=-Ausbreitung in die andere Richtung ist nicht betroffen, d.h. Einhangungen, die im Rechner erstellt werden, tauchen im Allgemeinen im Namensraum der Unit auf und Einhangungen, die auf dem Rechner entfernt werden, verschwinden auch dort. Beachten Sie insbesondere, dass die Einhangeausbreitung vom Rechner zu der Unit dazu fuhrt, dass unveranderte Einhangungen im Namensraum der Unit erstellt werden, d.h. schreibbare Einhangungen, die auf dem Rechner auftauchen, werden auch im Namensraum der Unit schreibbar sein, selbst wenn sie zu einem Pfad ausgebreitet werden, der mit ReadOnlyPaths= markiert ist! Daher wird die Zugriffseinschrankung mit diesen Optionen nicht auf Untereinhangungen eines Verzeichnisses, das spater erstellt wird, ausgeweitet. Dies bedeutet, dass die durch diese Einstellung angebotene Sperrung nicht vollstandig ist und keinen vollstandigen Schutz bietet. Beachten Sie, dass die Wirkung dieser Einstellung durch privilegierte Prozesse zuruckgenommen werden kann. Um eine wirksame Sandbox-Umgebung fur eine Unit einzurichten, wird daher empfohlen, diese Einstellungen mit entweder CapabilityBoundingSet=~CAP_SYS_ADMIN oder SystemCallFilter=~@mount zu kombinieren. Seien Sie besonders vorsichtig, wenn Sie diese Optionen fur API-Dateisysteme verwenden (eine Liste dieser konnen Sie unter MountAPIVPS= finden), da sie fur grundlegende Systemfunktionalitat notwendig sein konnen. Desweitern muss /run/ schreibbar sein, um Einhangenamensraume und Weiterleitung einzurichten. Beispiel fur eine einfache Erlaubnisliste mittels dieser Direktiven: [Service] ReadOnlyPaths=/ ReadWritePaths=/var /run InaccessiblePaths=-/lost+found NoExecPaths=/ ExecPaths=/usr/sbin/mein_Daemon /usr/lib /usr/lib64 Diese Optionen sind nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= implizit aktiviert (benotigt Unterstutzung fur nicht privilegierte Benutzernamensraume im Kernel mittels des Sysctl >>.kernel.unprivileged_userns_clone=<<). Hinzugefugt in Version 231. TemporaryFileSystem= Akzeptiert eine Leerzeichen-getrennte Liste von Einhangepunkten fur temporare Dateisysteme (tmpfs). Falls gesetzt, wird ein neuer Dateisystemnamensraum fur ausgefuhrte Prozesse eingerichtet und in jeden Einhangepunkt ein temporares Dateisystem eingehangt. Diese Option kann mehr als einmal angegeben werden, dann werden an allen aufgefuhrten Einhangepunkten temporare Dateisysteme eingehangt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste zuruckgesetzt und alle vorherigen Zuweisungen haben keinen Effekt. Jedem Einhangepunkt darf optional ein Doppelpunkt (>>:<<) und Einhangeoptionen wie >>size=10%<< oder >>ro<< angehangt werden. Standardmassig wird jedes temporare Dateisystem mit >>nodev,strictatime,mode=0755<< eingehangt. Dies kann durch explizite Angabe der entsprechenden Einhangeoptionen deaktiviert werden, z.B. >>dev<< oder >>nostrictatime<<. Dies ist nutzlich, um Dateien oder Verzeichnisse, die fur die von der Unit gestarteten Prozesse nicht relevant sind, zu verstecken, wahrend auf notwendige Dateien oder Verzeichnisse durch Kombination mit BindPaths= oder BindReadOnlyPaths= weiterhin zugegriffen werden kann: Beispiel: Falls eine Unit die Einstellunng TemporaryFileSystem=/var:ro BindReadOnlyPaths=/var/lib/systemd Der durch die Unit aufgerufene Prozess kann dann keine Dateien, Verzeichnisse oder Inhalte unter /var/ ausser /var/lib/systemd sehen. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 238. PrivateTmp= Akzeptiert ein logisches Argument. Falls wahr, wird ein neuer Dateisystemnamensraum fur den ausgefuhrten Prozess eingerichtet und private /tmp/- und /var/tmp/-Verzeichnisse darin eingehangt, die nicht mit Prozessen ausserhalb des Namensraums gemeinsam genutzt werden. Dies ist nutzlich, um Zugriff auf temporare Dateien des Prozesses abzusichern, allerdings ist die gemeinsame Benutzung von Inhalten uber /tmp/ oder /var/tmp/ mit anderen Prozessen unmoglich. Falls >>wahr<<, werden alle durch einen Dienst in diesen Verzeichnissen erstellten temporaren Dateien entfernt, nachdem der Dienst gestoppt ist. Standardmassig falsch. Es ist moglich, zwei oder mehr Units mit dem gleichen privaten /tmp/- und /var/tmp/-Namensraum durch Verwendung der Anweisung JoinsNamespaceOf= zu benutzen, siehe systemd.unit(5) fur Details. Diese Einstellung ist impliziert, falls DynamicUser= gesetzt ist. Fur diese Einstellung gelten die gleichen Beschrankungen bezuglich Einhangeausbreitung und Privilegien wie fur ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Aktivieren dieser Einstellung hat den Seiteneffekt des Hinzufugens der Abhangigkeiten Requires= und After= zu allen fur den Zugriff auf /tmp/ und /var/tmp/ notwendigen Einhange-Units. Desweiteren wird eine implizite After=-Ordnung auf systemd-tmpfiles-setup.service(8) hinzugefugt. Beachten Sie, dass die Implementierung dieser Einstellung unmoglich sein konnte (beispielsweise, falls Einhangenamensraume nicht verfugbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschliesslich auf diese Einstellung fur die Sicherheit verlasst. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). PrivateDevices= Akzeptiert ein logisches Argument. Falls wahr, wird eine neue /dev/-Einhangung fur den ausgefuhrten Prozess eingerichtet und nur API-Pseudogerate wie /dev/null, /dev/zero oder /dev/random (sowie das Pseudo-TTY-Untersystem) hinzugefugt, aber keine physischen Gerate wie /dev/sda, Systemspeicher /dev/mem, System-Ports /dev/port und andere. Dies ist nutzlich, um Zugriff auf physische Gerate fur ausgefuhrte Prozesse abzustellen. Standardmassig falsch. Aktivieren dieser Option wird einen Systemaufruffilter installieren, um systemnahe E/A-Systemaufrufe, die in der Gruppe @raw-io versammelt sind, zu blockieren, CAP_MKNOD und CAP_SYS_RAWIO aus der Capability-Begrenzungsmenge fur die Unit zu entfernen und DevicePolicy=closed zu setzen (siehe systemd.resource-control(5) fur Details). Beachten Sie, dass die Verwendung dieser Einstellung die Ausbreitung von Einhangungen aus dem Dienst zum Rechner trennen wird (Ausbreitung in die umgekehrte Richtung wird weiterhin funktionieren). Dies bedeutet, dass diese Einstellung nicht fur Dienste benutzt werden kann, die in der Lage sein sollen, Einhangepunkte in dem Haupteinhangeraum zu installieren. Das neue /dev/ wird nur lesbar und >>noexec<< eingehangt. Letzteres konnte alte Programme beschadigen, die mit mmap(2) aus /dev/zero ausfuhrbaren Speicher einrichten, statt MAP_ANON zu verwenden. Fur diese Einstellung gelten die gleichen Einschrankungen im Hinblick auf Einhangeausbreitung und Privilegien wie fur ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Beachten Sie, dass die Implementierung dieser Einstellung unmoglich sein konnte (beispielsweise, falls Einhangenamensraume nicht verfugbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschliesslich auf diese Einstellung fur die Sicherheit verlasst. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Wenn Zugriff auf einige aber nicht alle Gerate moglich sein soll, kann stattdessen die Einstellung DeviceAllow= verwandt werden. Siehe systemd.resource-control(5). Hinzugefugt in Version 209. PrivateNetwork= Akzeptiert ein logisches Argument. Falls wahr, wird ein Netzwerknamensraum fur die ausgefuhrten Prozesse eingerichtet und darin nur das Loopback-Netzwerkgerat >>lo<< konfiguriert. Dem ausgefuhrten Prozess wird kein anderes Netzwerkgerat zur Verfugung stehen. Dies ist nutzlich, um den ausgefuhrten Prozessen den Netzwerkzugriff zu verweigern. Standardmassig falsch. Es ist moglich, zwei oder mehr Units mit dem gleichen privaten Netzwerknamensraum durch Verwendung der Anweisung JoinsNamespaceOf= zu benutzen, siehe systemd.unit(5) fur Details. Beachten Sie, dass diese Option alle Socket-Einrichtungen, einschliesslich AF_NETLINK und AF_UNIX, vom Rechner trennen wird. Effektiv bedeutet das fur AF_NETLINK, dass von systemd-udevd.service(8) empfangene Geratekonfigurationsereignisse nicht zu den Prozessen der Unit ausgeliefert werden. Und fur AF_UNIX hat dies den Effekt, dass AF_UNIX-Sockets in dem abstrakten Namensraum des Rechners fur Prozesse der Unit unverfugbar werden (allerdings werden solche im Dateisystem weiterhin zugreifbar sein). Beachten Sie, dass die Implementierung dieser Einstellung unmoglich sein konnte (beispielsweise, falls Netzwerknamensraume nicht verfugbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschliesslich auf diese Einstellung fur die Sicherheit verlasst. Wenn diese Option aktiviert ist, wird PrivateMounts= impliziert, ausser es ist explizit deaktiviert und /sys wird neu eingehangt, um es mit dem neuen Netzwerknamensraum zu assoziieren. Wenn diese Option auf einer Socket-Unit verwandt wird, dann werden alle im Auftrag dieser Unit angebundenen Sockets innerhalb eines privaten Netzwerknamensraums angebunden. Dies kann mit JoinsNamespaceOf= kombiniert werden, um auf Sockets innerhalb von Netzwerknamensraumen von anderen Diensten auf Anfragen zu warten. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). NetworkNamespacePath= Akzeptiert einen absoluten Dateisystempfad, der sich auf eine Linux-Netzwerknamensraum-Pseudodatei bezieht (d.h. einer Datei wie /proc/$PID/ns/net oder einer Bind-Einhangung oder einem Symlink darauf). Ist dies gesetzt, dann werden aufgerufene Prozesse zu dem durch diesen Pfad referenzierten Netzwerknamensraum hinzugefugt. Der Pfad muss zum Zeitpunkt des Aufrufs von >>fork<< auf eine gultige Netzwerknamensraumdatei zeigen. Falls diese Option verwandt wird, hat PrivateNetwork= keine Wirkung. Falls diese Option zusammen mit JoinsNamespaceOf= verwandt wird, dann hat sie nur eine Wirkung, falls diese Unit gestartet wird, bevor alle der aufgefuhrten Units, die PrivateNetwork= oder NetworkNamespacePath= konfiguriert haben, gestartet wird, da andernfalls der Netzwerknamensraum dieser Units neu verwendet wird. Wenn diese Option aktiviert ist, wird PrivateMounts= impliziert, ausser es ist explizit deaktiviert und /sys wird neu eingehangt, um es mit dem neuen Netzwerknamensraum zu assoziieren. Wenn diese Option auf einer Socket-Unit verwandt wird, dann werden alle Sockets, die im Auftrag dieser Units angebunden sind, innerhalb des festgelegten Netzwerknamensraums angebunden. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 242. PrivateIPC= Akzeptiert ein logisches Argument. Falls wahr, wird ein neuer IPC-Namensraum fur den ausgefuhrten Prozess eingerichtet. Jeder IPC-Namensraum hat seine eigene Gruppe an System-V-IPC-Kennzeichnern und sein eigenes POSIX-Nachrichtenwarteschlangen-Dateisystem. Dies ist zur Vermeidung von Namens-Kollisionen bei IPC-Kennzeichnern nutzlich. Standardmassig falsch. Es ist moglich, zwei oder mehr Units innerhalb des gleichen privaten IPC-Namensraum auszufuhren, indem die Direktive JoinsNamespaceOf= verwandt wird, siehe systemd.unit(5) fur Details. Beachten Sie, dass IPC-Namensraume keinerlei Auswirkung auf AF_UNIX-Sockets haben, die die haufigste Form von IPC unter Linux sind. Stattdessen unterliegen AF_UNIX in dem Dateisystem den Einhangenamensraumen. IPC-Namensraume haben nur eine Auswirkung auf SysV-IPC (was grosstenteils veraltet ist), sowie POSIX-Nachrichtenwarteschlangen (fur die AF_UNIX-/SOCK_SEQPACKET-Sockets typischerweise die bessere Alternative sind). IPC-Namensraume haben auch keine Auswirkungen auf gemeinsam benutzten Speicher gemass POSIX (der Einhangenamensraumen unterliegt). Siehe ipc_namespaces(7) fur Details. Beachten Sie, dass die Implementierung dieser Einstellung unmoglich sein konnte (beispielsweise, falls IPC-Namensraume nicht verfugbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschliesslich auf diese Einstellung fur die Sicherheit verlasst. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 248. IPCNamespacePath= Akzeptiert einen absoluten Dateisystempfad, der sich auf eine Linux-IPC-Namensraum-Pseudodatei bezieht (d.h. einer Datei wie /proc/$PID/ns/ipc oder einer Bind-Einhangung oder einem Symlink darauf). Ist dies gesetzt, dann werden aufgerufene Prozesse zu dem durch diesen Pfad referenzierten Netzwerknamensraum hinzugefugt. Der Pfad muss zum Zeitpunkt des Aufrufs von >>fork<< auf eine gultige Netzwerknamensraumdatei zeigen. Falls diese Option verwandt wird, hat PrivateIPC= keine Wirkung. Falls diese Option zusammen mit JoinsNamespaceOf= verwandt wird, dann hat sie nur eine Wirkung, falls diese Unit gestartet wird, bevor alle der aufgefuhrten Units, die PrivateIPC= oder IPCNamespacePath= konfiguriert haben, gestartet wird, da andernfalls der Netzwerknamensraum dieser Units neu verwendet wird. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 248. MemoryKSM= Akzeptiert ein logisches Argument. Wenn gesetzt, aktiviert es KSM (Zusammenfuhrung gleicher Seiten des Kernels) fur den Prozess. KSM ist eine speichersparende Deduplizierungsfunktionalitat. Anonyme Speicherseiten mit identischem Inhalt konnen durch eine einzelne, schreibgeschutzte Seite ersetzt werden. Diese Funktionalitat sollte nur fur Auftrage aktiviert werden, die in der gleichen Sicherheitsdomane sind. Zu Details siehe Kernel Samepage Merging[7] in der Kerneldokumentation. Beachten Sie, dass diese Funktionalitat nicht verfugbar sein konnte, beispielsweise falls KSM im Kernel deaktiviert wurde oder der Kernel die Steuerung von KSM auf der Prozessebene mittels prctl(2) nicht unterstutzt. Hinzugefugt in Version 254. PrivateUsers= Akzeptiert ein logisches Argument. Falls wahr, richtet es einen neuen Benutzernamensraum fur den ausgefuhrten 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 nutzlich, um die von der Unit verwandte Benutzer- und Gruppendatenbank sicher vom Rest des Systems abzutrennen und daher eine effektive Sandbox-Umgebung zu erstellen. Alle Dateien, Verzeichnisse, Prozesse, IPC-Objekte und andere Ressourcen, die nicht >>root<< (Benutzer/Gruppe) oder der Unit-eigenen gehoren, bleiben von innerhalb der Unit sichtbar, scheinen aber dem Benutzer und der Gruppe >>nobody<< zu gehoren. Falls dieser Modus aktiviert ist, werden alle Unit-Prozesse ohne Privilegien in dem Systembenutzernamensraum ausgefuhrt (unabhangig davon, ob der Benutzer / die Gruppe der Unit >>root<< ist oder nicht). Dies bedeutet insbesondere, dass der Prozess uber keine Prozess-Capabilities im Systembenutzerraum, aber uber volle Capabilities innerhalb des Benutzernamensraums des Dienstes verfugen wird. Einstellungen wie CapabilityBoundingSet= beeinflussen nur Letzteren und es gibt keine Moglichkeit, zusatzliche Capabilities im Benutzerraum des Systems zu erlangen. Standardmassig aus. Wenn diese Einstellung durch eine benutzerbezogene Instanz des Diensteverwalters eingerichtet ist, entfallt die Abbildung des Benutzers und der Gruppe >>root<< auf sich selbst (ausser der Benutzerverwalter ist root). Im Falle des benutzerbezogenen Instanzverwalters wird der Namensraum zusatzlich vor den meisten anderen Namensraumen eingerichtet. Das bedeutet, dass die Kombination von PrivateUsers=true mit anderen Namensraumen die Verwendung von Funktionalitaten aktiviert, die normalerweise von benutzerbezogenen Instanzen des Diensteverwalters nicht unterstutzt werden. Diese Einstellung ist insbesondere im Zusammenspiel mit RootDirectory=/RootImage= nutzlich, 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 mussen, >>root<<, >>nobody<< und der Benutzer und die Gruppe der Unit selbst sind. Beachten Sie, dass die Implementierung dieser Einstellung unmoglich sein konnte (beispielsweise, falls Benutzernamensraume nicht verfugbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschliesslich auf diese Einstellung fur die Sicherheit verlasst. Hinzugefugt in Version 232. ProtectHostname= Akzeptiert ein logisches Argument. Wenn gesetzt, wird ein neuer UTS-Namensraum fur den ausgefuhrten Prozess eingerichtet. Zusatzlich wird die Veranderung des >>hostname<< oder >>domainname<< verhindert. Standardmassig >>off<<. Beachten Sie, dass die Implementierung dieser Einstellung unmoglich sein konnte (beispielsweise, falls UTS-Namensraume nicht verfugbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschliesslich auf diese Einstellung fur die Sicherheit verlasst. Beachten Sie, dass Anderungen des >>hostname<< sich nicht langer vom System in den Dienst ausbreiten, wenn diese Option fur einen Dienst aktiviert ist. Daher ist sie nicht fur Dienste geeignet, die dynamisch die Anderung des >>hostname<< des Systems beachten sollen. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 242. ProtectClock= Akzeptiert ein logisches Argument. Falls wahr, werden Schreibzugriffe auf die Hardware- oder System-Uhr verweigert. Standardmassig aus. Aktivierung dieser Option entfernt CAP_SYS_TIME und CAP_WAKE_ALARM aus der Capability-Begrenzungsmenge fur diese Unit, installiert einen Systemaufruffilter, um Systemaufruf zu blockieren, die die Uhr stellen und DeviceAllow=char-rtc r ist impliziert. Beachten Sie, dass die Systemaufrufe insgesamt blockiert sind, der Filter berucksichtigt nicht, dass einige der Aufrufe zum Lesen des Uhrzustandes mit einigen Parameterkombinationen verwandt werden konnen. Effektiv werden dadurch /dev/rtc0, /dev/rtc1 usw. fur den Dienst nur lesbar. Siehe systemd.resource-control(5) fur die Details von DeviceAllow=. Fur die meisten Dienste, die die Uhr nicht verandern oder ihren Zustand prufen mussen, wird empfohlen, dies einzuschalten. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 245. ProtectKernelTunables= Akzeptiert ein logisches Argument. Falls wahr, sind die durch /proc/sys/, /sys/, /proc/sysrq-trigger, /proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs und /proc/irq verfugbaren Kernelvariablen fur alle Prozesse der Unit nur lesbar. Normalerweise sollten einstellbare Kernelvariablen nur zum Systemstartzeitpunkt initialisiert werden, beispielsweise uber den Mechanismus sysctl.d(5). Zur Laufzeit mussen wenige Dienste diese schreiben, es wird daher empfohlen, dies fur die meisten Dienste einzuschalten. Fur diese Einstellung gelten die gleichen Einschrankungen bezuglich Einhangeausbreitung und Privilegien wie fur ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Standardmassig aus. Beachten Sie, dass diese Option keine indirekten Anderungen an Kerneleinstellungen, die durch IPC-Aufrufe an andere Prozesse erfolgen, verhindert. Allerdings kann InaccessiblePaths= verwandt werden, um die relevanten IPC-Dateisystemobjekte unzugreifbar zu machen. Falls ProtectKernelTunables= gesetzt ist, wird MountAPIVFS=yes impliziert. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 232. ProtectKernelModules= Akzeptiert ein logisches Argument. Falls wahr, wird das explizite Laden von Modulen verweigert. Dies erlaubt es, das Modulladen und -entladen fur modulare Kernel abzuschalten. Es wird empfohlen, dieses fur die meisten Dienste, die keine besonderen Dateisysteme oder zusatzliche Kernelmodule fur ihre Arbeit benotigen, einzuschalten. Standardmassig aus. Einschalten dieser Option entfernt CAP_SYS_MODULE aus der Capability-Begrenzungsmenge fur die Unit und installiert einen Systemaufruffilter, um Modulsystemaufrufe zu blockieren; sie macht auch /usr/lib/modules unzugreifbar. Fur diese Einstellungen gelten die gleichen Einschrankungen bezuglich Einhangeausbreitung und Privilegien wie fur ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Beachten Sie, dass begrenztes automatisches Modulladen aufgrund von Benutzerkonfiguration oder Kernelabbildungstabellen als Seiteneffekt von angefragten Benutzeraktionen, sowohl privilegiert als auch unprivilegiert, weiterhin vorkommen kann. Um die Funktionalitat des automatischen Modulladens zu deaktivieren, lesen Sie bitte die Dokumentation zum Mechanismus kernel.modules_disabled von sysctl.d(5) und /proc/sys/kernel/modules_disabled. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 232. ProtectKernelLogs= Akzeptiert ein logisches Argument. Falls wahr, wird der Zugriff auf den Kernelprotokollringpuffer verweigert. Fur die meisten Dienste, die den Kernelprotokollringpuffer weder lesen noch schreiben mussen, wird empfohlen, dies einzuschalten. Aktivierung dieser Option entfernt CAP_SYSLOG aus der Capability-Begrenzungsmenge fur diese Unit und installiert einen Systemaufruffilter, um den Systemaufruf syslog(2) (der nicht mit der Libc-API syslog(3) fur Benutzerprotokollierung durcheinandergebracht werden darf) blockiert. Der Kernel legt seinen Protokollpuffer mittels /dev/kmsg und /proc/kmsg offen. Falls aktiviert, werden diese fur alle Prozesse der Unit nicht mehr zugreifbar sein. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 244. ProtectControlGroups= Akzeptiert ein logisches Argument. Falls wahr, werden die uber /sys/fs/cgroup/ erreichbaren >>Linux Control Groups<< (cgroups(7))-Hierarchien fur alle der Prozesse nur lesbar sein. Ausser fur Container-Verwalter sollte kein Dienst Schreibzugriff auf diese Control-Gruppenhierarchie benotigen; es wird daher empfohlen, dies fur die meisten Dienste einzuschalten. Fur diese Einstellungen gelten die gleichen Einschrankungen bezuglich Einhangeausbreitung und Privilegien wie fur ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Standardmassig aus. Falls ProtectControlGroups= gesetzt ist, wird MountAPIVFS=yes impliziert. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 232. RestrictAddressFamilies= Beschrankt die Gruppe der Socket-Adressfamilien, auf die Prozesse dieser Unit zugreifen konnen. Akzeptiert >>none<< oder eine Leerzeichen-getrennte Liste von freizugebenden Adressfamiliennamen, wie AF_UNIX, AF_INET oder AF_INET6. Wird >>none<< festgelegt, dann werden alle Adressfamilien verboten. Wird der Liste >>~<< vorangestellt, wird die Liste der Adressfamilien als Ausschlussliste angewandt, andernfalls als Freigabeliste. Beachten Sie, dass dies nur Zugriff auf den Systemaufruf socket(2) beschrankt. Sockets, die auf anderem Wege in die Unit hereingegeben werden (beispielsweise durch Verwendung von Socket-Aktivierung mit Socket-Units, siehe systemd.socket(5)) sind davon nicht betroffen. Auch Sockets, die mit socketpair() (was nur verbundene AF_UNIX-Sockets erstellt) erstellt werden, sind nicht betroffen. Beachten Sie, das diese Option keinen Effekt auf 32-Bit X86, S390, S390x, MIPS, MIPS-le, PPC, PPC-le, PPC64, PPC64-le hat und ignoriert wird (funktioniert aber auf anderen ABIs, einschliesslich x86-64, korrekt). Beachten Sie, dass auf Systemen, die mehrere ABIs unterstutzen (wie X86/X86-64), empfohlen wird, alternative ABIs fur Dienste zu deaktivieren, so dass sie nicht zur Umgehung der Einschrankungen dieser Option verwandt werden konnen. Insbesondere wird empfohlen, diese Option mit SystemCallArchitectures=native oder ahnlichem zu kombinieren. Standardmassig werden keine Einschrankungen angewandt, Prozesse konnen auf alle Adressfamilien zugreifen. Falls die leere Zeichenkette zugewiesen wird, werden alle vorherigen Anderungen der Einschrankung der Adressfamilie zuruckgenommen. Diese Einstellung betrifft keine Befehle, denen >>+<< vorangestellt sind. Verwenden Sie diese Option, um den Kontakt des Prozesses fur Zugriff aus der Ferne, insbesondere uber exotische und heikle Netzwerkprotokolle wie AF_PACKET, zu begrenzen. Beachten Sie, dass in den meisten Fallen die lokale Adressfamilie AF_UNIX in die konfigurierte Freigabeliste aufgenommen werden sollte, da sie haufig fur lokale Kommunikation verwandt wird, einschliesslich fur die syslog(2)-Protokollierung. Hinzugefugt in Version 211. RestrictFileSystems= Beschrankt die Menge der Dateisysteme, auf denen Prozesse dieser Unit Dateien offnen konnen. Akzeptiert eine Doppelpunkt-getrennte Liste von Dateisystemnamen. Alle aufgefuhrten Dateisysteme werden fur die Prozesse der Unit zugreifbar gemacht, Zugriff auf nicht aufgefuhrte Dateisysteme wird verboten (Erlaubnisliste). Falls das erste Zeichen der Liste >>-<< ist, wird die Auswirkung invertiert: Zugriff auf die aufgefuhrten Dateisystem wird verboten (Ausschlussliste). Falls die leere Zeichenkette zugewiesen wird, wird der Zugriff auf Dateisysteme nicht beschrankt. Falls Sie beide Arten dieser Option (d.h. explizite Freischaltung und Ausschlussliste) festlegen, wird die erste angetroffene Vorrang haben und die Standardaktion festlegen (Erlauben oder Verweigern des Zugriffs auf das Dateisystem). Dann wird das nachste Auftreten dieser Option die Liste der Dateisysteme zu der Menge der beschrankten Dateisysteme hinzufugen oder aus dieser loschen, abhangig von seiner Art und der Standardaktion. Beispiel: Falls eine Unit die Einstellunng RestrictFileSystems=ext4 tmpfs RestrictFileSystems=ext2 ext4 Dann wird der Zugriff auf ext4, tmpfs und ext2 erlaubt und Zugriff auf andere Dateisysteme verweigert. Beispiel: Falls eine Unit die Einstellunng RestrictFileSystems=ext4 tmpfs RestrictFileSystems=~ext4 Dann wird nur der Zugriff auf tmpfs erlaubt. Beispiel: Falls eine Unit die Einstellunng RestrictFileSystems=~ext4 tmpfs RestrictFileSystems=ext4 Dann wird nur der Zugriff auf tmpfs verweigert. Da die Anzahl der moglichen Dateisysteme gross ist, werden vordefinierte Gruppen von Dateisystemen bereitgestellt. Eine Gruppe beginnt mit dem Zeichen >>@<<, gefolgt vom Namen der Gruppe. Tabelle 3. Derzeit vordefinierte Dateisystemgruppen +------------------+-----------------------------+ |Gruppe | Beschreibung | +------------------+-----------------------------+ |@basic-api | Grundlegende | | | Dateisystem-API. | +------------------+-----------------------------+ |@auxiliary-api | Hilfs-Dateisystem-API. | +------------------+-----------------------------+ |@common-block | Gebrauchliche | | | Blockgerate-Dateisysteme. | +------------------+-----------------------------+ |@historical-block | Historische | | | Blockgerate-Dateisysteme. | +------------------+-----------------------------+ |@network | Gut bekannte | | | Netzwerk-Dateisysteme. | +------------------+-----------------------------+ |@privileged-api | Privilegierte Dateisystem | | | API. | +------------------+-----------------------------+ |@temporary | Temporare Dateisysteme: | | | tmpfs, ramfs. | +------------------+-----------------------------+ |@known | Alle durch den Kernel | | | definierten bekannten | | | Dateisysteme. Diese Liste | | | ist in Systemd statisch | | | basierend auf der | | | Kernelversion, die bei der | | | Veroffentlichung von | | | Systemd verfugbar war, | | | definiert. Sie wird | | | fortschreitend veralten, | | | wenn der Kernel | | | aktualisiert wird. | +------------------+-----------------------------+ Verwenden Sie den Befehl filesystems von systemd-analyze(1), um eine Liste von Dateisystemen abzufragen, die auf dem lokalen System definiert sind. Beachten Sie, dass diese Einstellung auf einigen Systemen nicht unterstutzt werden konnte (beispielsweise weil der LSM-eBFP-Hook in dem zugrundeliegenden Kernel nicht aktiviert wurde oder falls die vereinigte Control-Gruppen-Hierarchie nicht verwandt wird). In diesem Fall hat diese Einstellung keine Auswirkung. Diese Option kann nicht durch Voranstellen von >>+<< vor den Ausfuhrungspfad in der Dienste-Unit umgangen werden, da sie fur die gesamte Control-Gruppe gilt. Hinzugefugt in Version 250. RestrictNamespaces= Begrenzt Zugriff auf die Linux-Namensraumfunktionalitat fur die Prozesse dieser Unit. Fur Details uber Linux-Namensraume siehe namespaces(7). Akzeptiert entweder ein logisches Argument oder eine Leerraum-getrennte Liste von Namensraumtypkennzeichnern. Falls falsch (die Vorgabe), erfolgen keine Beschrankungen bezuglich Namensraumerstellung und -umschaltung. Andernfalls muss eine Leerzeichen-getrennte Liste von Namensraumtypkennzeichnern festgelegt werden, die aus einer Kombination von cgroup, ipc, net, mnt, pid, user und uts bestehen. Jeder aufgefuhrte Namensraumtyp wird den Prozessen der Unit zugreifbar gemacht, Zugriff auf nicht aufgefuhrte Namensraume sind verboten (Freigabeliste). Durch Voranstellen des Tilde-Zeichens (>>~<<) kann der Effekt invertiert werden: nur die aufgefuhrten Namensraumtypen werden nicht zugreifbar gemacht, alle nicht aufgefuhrten sind erlaubt (Verbotsliste). Falls die leere Zeichenkette zugewiesen wird, werden die Vorgabe-Namensraumeinschrankungen angewandt, was zu falsch aquivalent ist. Diese Option kann mehr als einmal auftauchen. In diesem Fall werden die Namensraumtypen mit ODER (oder mit UND, falls den Zeilen >>~<< vorangestellt wird) zusammengefasst (siehe nachfolgende Beispiele). Intern begrenzt diese Einstellung Zugriff auf die Systemaufrufe unshare(2), clone(2) und setns(2) und berucksichtigt dabei die festgelegten Schalterparameter. Beachten Sie, dass bei Verwendung dieser Option zusatzlich zur Begrenzung der Erstellung und Umschaltung der festgelegten Namensraumtypen (oder allen von ihnen, falls wahr) Zugriff auf den Systemaufruf setns() mit einem Nullschalterparameter verboten ist. Diese Einstellung wird nur auf X86, X86-64, MIPS, MIPS-le, MIPS64, MIPS64-le, MIPS64-n32, MIPS64-le-n32, PPC64, PPC64-le, S390 und S390x unterstutzt und erwirkt auf anderen Architekturen keine Einschrankungen. Beispiel: Falls eine Unit die Einstellunng RestrictNamespaces=cgroup ipc RestrictNamespaces=cgroup net hat, dann werden cgroup, ipc und net gesetzt. Falls der zweiten Zeile >>~<< vorangestellt wird, d.h. RestrictNamespaces=cgroup ipc RestrictNamespaces=~cgroup net dann wird nur ipc gesetzt. Hinzugefugt in Version 233. LockPersonality= Akzeptiert ein logisches Argument. Falls gesetzt, sperrt es den Systemaufruf personality(2), so dass die Kernel-Ausfuhrungsdomane nicht mehr von der Vorgabe oder von der mit der Anweisung Personality= ausgewahlten Personalitat geandert werden kann. Dies kann zur Verbesserung der Sicherheit nutzlich sein, da merkwurdige Personalitatsemulationen schlecht getestet und eine Quelle von Schwachstellen sein konnen. Hinzugefugt in Version 235. MemoryDenyWriteExecute= Akzeptiert ein logisches Argument. Falls gesetzt, werden Versuche, Speicher-Mappings zu erstellen, die gleichzeitig schreib- und ausfuhrbar sind oder bestehende Speicher-Mappings zu andern, dass sie ausfuhrbar werden oder gemeinsame Speichersegmente als ausfuhrbar zu mappen, verboten. Insbesondere wird ein Systemaufruffilter hinzugefugt (oder, bevorzugt, wird eine aquivalente Kerneluberprufung mittels prctl(2) aktiviert), der mmap(2)-Systemaufrufe mit sowohl gesetztem PROT_EXEC als auch gesetztem PROT_WRITE, mprotect(2)- oder pkey_mprotect(2)-Systemaufrufe mit gesetztem PROT_EXEC und shmat(2)-Systemaufrufe mit gesetztem SHM_EXEC zuruckgewiesen. Beachten Sie, dass diese Option mit Programmen und Bibliotheken, die Code dynamisch zur Laufzeit erstellen, inkompatibel ist. Zu dieser Gruppe gehoren JIT-Ausfuhrungsmaschinen, ausfuhrbare Stacks und Code->>Trampolin<<-Funktionalitaten verschiedener C-Compiler. Diese Option verbessert die Sicherheit, da es Software-Exploits erschwert, dynamisch laufenden Code zu andern. Allerdings kann der Schutz umgangen werden, falls der Dienst in ein Dateisystem schreiben kann, das nicht mit der Option noexec eingehangt ist (wie /dev/shm) oder er memfd_create() verwenden kann. Dies kann verhindert werden, indem solche Dateisysteme fur den Dienst unzugreifbar gemacht (z.B. InaccessiblePaths=/dev/shm) und weitere Systemaufruffilter (SystemCallFilter=~memfd_create) installiert werden. Beachten Sie, dass diese Funktionalitat komplett auf X86-64 und teilweise auf X86 verfugbar ist. Insbesondere der shmat()-Schutz ist auf X86 nicht verfugbar. Beachten Sie, dass auf Systemen, die mehrere ABIs unterstutzen (wie X86/X84-64), es empfohlen wird, alternative ABIs fur Dienste auszuschalten, so dass diese nicht zur Umgehung der Einschrankungen durch diese Option verwandt werden konnen. Insbesondere wird empfohlen, diese Option mit SystemCallArchitectures=native oder ahnlichem zu kombinieren. Hinzugefugt in Version 231. RestrictRealtime= Akzeptiert ein logisches Argument. Falls gesetzt, werden alle Versuche, Echtzeit-Scheduling fur einen Prozess der Unit zu aktivieren, abgelehnt. Damit wird Zugriff auf die Echtzeitprogramm-Scheduling-Richtlinien wie SCHED_FIFO, SCHED_RR oder SCHED_DEADLINE begrenzt. Siehe sched(7) fur Details uber diese Scheduling-Richtlinien. Echtzeit-Scheduling-Richtlinien konnen zur Monopolisierung von CPU-Zeit fur langere Zeitperioden verwandt werden und konnen daher dazu verwandt werden, das System zu sperren oder anderweitige Diensteverweigerungssituationen auf dem System auszulosen. Es wird daher empfohlen, den Zugriff auf Echtzeit-Scheduling auf die wenigen Programme, die dies tatsachlich benotigen, zu begrenzen. Standardmassig aus. Hinzugefugt in Version 231. RestrictSUIDSGID= Akzeptiert ein logisches Argument. Falls gesetzt, werden alle Versuche, die Bits >>set-user-ID<< (SUID) oder >>set-group-ID<< (SGID) auf Dateien oder Verzeichnissen zu setzen, verweigert (fur Details uber diese Bits siehe inode(7)). Da SUID/SGID ein Mechanismus zur Erhohung der Rechte ist und Benutzern erlaubt, die Identitat anderer Benutzer zu erlangen, wird empfohlen, die Erstellung von SUID/SGID-Dateien auf die wenigen Programme zu beschranken, die dies tatsachlich benotigen. Beachten Sie, dass dies die Markierung jeder Art von Dateisystemobjekt mit diesen Bits beschrankt, einschliesslich regularer Dateien und Verzeichnisse (auf denen das Bit SGID eine andere Bedeutung als bei Dateien hat, siehe Dokumentation). Diese Option ist impliziert, falls DynamicUser= aktiviert ist. Standardmassig >>off<<. Hinzugefugt in Version 242. RemoveIPC= Akzeptiert ein logisches Argument. Falls gesetzt, werden alle System-V- und POSIX-IPC-Objekte, die dem Benutzer und der Gruppe, unter der diese Unit lauft, gehoren, entfernt, wenn die Unit gestoppt wird. Diese Einstellung hat nur einen Effekt, falls eines aus User=, Group= oder DynamicUser= verwandt wird. Es hat keinen Effekt fur IPC-Objekte, die dem Benutzer >>root<< gehoren. Insbesondere entfernt dies System-V-Semaphoren sowie gemeinsam benutzte Segmente und Nachrichten-Warteschlangen gemass System V und POSIX. Falls mehrere Units die gleichen Benutzer oder Gruppen verwenden, werden die IPC-Objekte entfernt, wenn die letzte dieser Units gestoppt wird. Diese Einstellung ist impliziert, falls DynamicUser= gesetzt ist. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 232. PrivateMounts= Akzeptiert einen logischen Parameter. Falls gesetzt, wird diese Unit in ihrem eigenen privaten Dateisystem (Einhange-)Namensraum betrieben, wobei alle Einhangeausbreitungen von dem Prozess in Richtung des Hauptdateisystems des Wirts abgeschaltet sind. Dies bedeutet, dass alle vom Prozess etablierten oder entfernten Dateisystemeinhangepunkte fur diese privat und nicht im Wirtsystem sichtbar sind. Allerdings werden Dateisystemeinhangepunkte, die auf dem Wirt etabliert oder entfernt werden, sich zu den Prozessen der Unit ausbreiten. Siehe mount_namespaces(7) fur Details bezuglich Dateisystemnamensraumen. Standardmassig aus. Falls eingeschaltet, wird dies drei Aktionen fur jeden aufgerufenen Prozess auslosen: ein neuer CLONE_NEWNS-Namensraum wird erstellt, danach werden alle existierenden Einhangungen neu als MS_SLAVE eingehangt, um die Ausbreitung aus den Prozessen der Unit zu dem Wirtsystem zu deaktivieren (aber die Ausbreitung in die umgekehrte Richtung bleibt wirksam). Schliesslich werden die Einhangungen erneut gemass des in dem Schalter MountFlags= konfigurierten Ausbreitungsmodus eingehangt, siehe unten. Dateisystemnamensraume werden individuell fur jeden mit >>fork<< vom Diensteverwalter gestarteten Prozess eingerichtet. Einhangungen, die im Namensraum des durch ExecStartPre= erstellten Prozesses etabliert wurden, werden daher automatisch bereinigt, sobald der Prozess sich beendet und werden fur nachfolgend durch ExecStart= mit Fork gestartete Prozesse nicht verfugbar sein (und Ahnliches gilt auch fur die verschiedenen anderen fur Units konfigurierten Befehle). Ahnlich erlaubt JoinsNamespaceOf= nicht die gemeinsame Benutzung von Kernelnamensraumen zwischen Units, es ermoglicht nur die gemeinsame Benutzung der Verzeichnisse /tmp/ und /var/tmp/. Andere Dateisystemnamensraume-Einstellungen fur Units -- PrivateMounts=, PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=, ReadOnlyPaths=, InaccessiblePaths=, ReadWritePaths=, -- ermoglichen Dateisystemnamensraume in einer Art ahnlich dieser Option. Daher ist es primar zur expliziten Anfrage dieses Verhalten nutzlich, falls keine der anderen Einstellungen verwandt wird. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). Hinzugefugt in Version 239. MountFlags= Akzeptiert eine Einhangeausbreitungseinstellung: shared, slave oder private, die steuert, ob Dateisystemeinhangepunkte, die fur die Prozesse dieser Unit in dem Dateisystemnamensraum eingerichtet wurden, Einhangungen oder Aushangungen aus anderen Dateisystemnamensraumen empfangen oder ausbreiten. Siehe mount(2) fur Details uber Einhangeausbreitungen und insbesondere die drei Ausbreitungsschalter. Diese Einstellung steuert nur die abschliessenden Ausbreitungseinstellungen, die fur alle Einhangepunkte des Dateisystemnamensraums, der fur jeden Prozess dieser Unit erstellt wurde, wirksam sind. Andere Dateisystemnamensraum-Unit-Einstellungen (siehe die Diskussion in PrivateMounts= oben) werden implizit Einhange- und Aushangeausbreitung von den Prozessen der Unit in Richtung des Systems deaktivieren, indem sie die Ausbreitungseinstellungen aller Einhangepunkte in dem Dateisystemnamensraum der Unit zuerst auf slave setzen. Setzen der Option auf shared richtet die Ausbreitung in diesem Fall nicht wieder ein. Falls nicht gesetzt - aber es sind durch andere Dateisystemnamensraumeinstellungen der Unit keine Dateisystemnamensraume aktiviert -, wird shared Einhangeausbreitung verwandt, aber wie erwahnt, wird slave zuerst angewandt, Ausbreitung von den Prozessen der Unit zum Wirtsystem bleibt weiterhin abgeschaltet. Es wird nicht empfohlen, private Einhangeausbreitung fur Units zu verwenden, da dies bedeutet, dass temporare Einhangungen (wie Wechselmedien) auf dem Wirtsystem eingehangt bleiben und daher unbefristet in mit Fork erstellten Programmen als beschaftigt markiert sind, da die Aushangeausbreitungsereignisse in dem Dateisystemnamensraum der Unit nicht empfangen werden. Normalerweise ist es am besten, diese Einstellung unverandert zu lassen und stattdessen abstraktere Dateisystemnamensraumoptionen zu verwenden, insbesondere PrivateMounts=, siehe oben. Diese Option ist nur fur Systemdienste verfugbar oder fur Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benotigt im Kernel mittels des Sysctl >>kernel.unprivileged_userns_clone=<< aktivierte Unterstutzung fur nicht privilegierten Benutzernamensraum). SYSTEMAUFRUFFILTERUNG SystemCallFilter= Akzeptiert eine Leerzeichen-getrennte Liste von Systemaufrufenamen. Falls diese Einstellung verwandt wird, werden alle Systemaufrufe, die durch die Prozesse der Unit ausgefuhrt werden, zu sofortiger Beendigung mit dem Signal SIGSYS fuhren, falls sie nicht aufgefuhrt sind (Freigabeliste). (Siehe SystemCallErrorNumber= zur Anderung der Standardaktion). Falls das erste Zeichen der Liste >>~<< ist, wird die Wirkung invertiert: nur die aufgefuhrten Systemaufrufe fuhren zu einer sofortigen Prozessbeendigung (Verbotsliste). Freigegebenen Systemaufrufen und Systemaufrufgruppen kann optional ein Doppelpunkt (>>:<<) und >>errno<<-Fehlernummern (zwischen 0 und 4095) oder Fehlernummernamen wie EPERM, EACCES oder EUCLEAN (siehe errno(3) fur eine komplette Liste) angehangt werden. Dieser Wert wird zuruckgeliefert, wenn ein verbotener Systemaufruf ausgelost wird, statt den Prozess sofort zu beenden. Die besondere Einstellung >>kill<< kann zur expliziten Angabe des Totens verwandt werden. Dieser Wert hat vor dem in SystemCallErrorNumber= angegebenen Vorrang, siehe unten. Diese Funktionalitat verwendet die Schnittstelle >>Secure Computing Mode 2<< des Kernels (>>Seccomp-Filterung<<) und ist nutzlich, um eine minimale Sandboxing-Umgebung zu erzwingen. Beachten Sie, dass die Systemaufrufe execve(), exit(), exit_group(), getrlimit(), rt_sigreturn(), sigreturn() und die Systemaufrufe zur Abfrage der Zeit und zum Schlafen implizit auf der Freigabeliste sind und nicht explizit aufgelistet werden mussen. Diese Option kann mehr als einmal angegeben werden, die Filtermasken werden in diesem Fall zusammengefuhrt. Falls die leere Zeichenkette zugewiesen wird, wird der Filter zuruckgesetzt und alle vorherigen Zuweisungen haben keine Wirkung. Diese betrifft Befehle, denen >>+<< vorangestellt ist, nicht. Beachten Sie, dass auf Systemen, die mehrere ABIs unterstutzen (wie X86/X86-64), empfohlen wird, alternative ABIs fur Dienste zu deaktivieren, so dass sie nicht zur Umgehung der Einschrankungen dieser Option verwandt werden konnen. Insbesondere wird empfohlen, diese Option mit SystemCallArchitectures=native oder Ahnlichem zu kombinieren. Beachten Sie, dass strenge Systemaufruffilterung die Ausfuhrungs- und Fehlerbehandlungs-Code-Pfade des Diensteaufrufs beeinflussen konnen. Insbesondere wird der Zugriff auf den Systemaufruf execve() fur die Ausfuhrung des Dienstprogrammes benutzt -- falls er blockiert ist, wird der Diensteaufruf notwendigerweise fehlschlagen. Falls auch die Ausfuhrung des Dienstprogramms aus irgendwelchen Grunden fehlschlagt (beispielsweise fehlendes Dienstprogramm), konnte die Fehlerbehandlungslogik Zugriff auf eine zusatzliche Gruppe an Systemaufrufen benotigen, um diesen Fehlschlag korrekt zu verarbeiten und zu protokollieren. Es konnte notwendig sein, temporar die Systemaufruffilter zu deaktivieren, um die Fehlersuche bei solchen Fehlschlagen zu vereinfachen. Falls Sie beide Arten dieser Option (d.h. explizite Freischaltung und Ausschlussliste) festlegen, wird die erste angetroffene Vorrang haben und die Standardaktion festlegen (Beendigung oder Bestatigung eines Systemaufrufs). Dann wird das nachste Auftreten dieser Option die Liste der Systemaufrufe zu der Menge der gefilterten Systemaufrufe hinzufugen oder aus dieser loschen, abhangig von seiner Art und der Standardaktion. (Falls Sie beispielsweise mit einer expliziten Freischaltung von read() und write() beginnen und direkt danach eine Ausschlussliste mit write() hinzufugen, dann wird write() aus der Menge entfernt.) Da die Anzahl der moglichen Systemaufrufe gross ist, werden vordefinierte Gruppen von Systemaufrufen bereitgestellt. Eine Gruppe beginnt mit dem Zeichen >>@<<, gefolgt vom Namen der Gruppe. Tabelle 4. Derzeit vordefinierte Systemaufrufgruppen +----------------+---------------------------------+ |Gruppe | Beschreibung | +----------------+---------------------------------+ |@aio | Asynchrone E/A (io_setup(2), | | | io_submit(2) und verwandte | | | Aufrufe) | +----------------+---------------------------------+ |@basic-io | Systemaufrufe fur grundlegende | | | E/A: Lesen, Schreiben, Suchen, | | | Duplizieren und Schliessen von | | | Dateideskriptoren (read(2), | | | write(2) und verwandte Aufrufe) | +----------------+---------------------------------+ |@chown | Anderung der | | | Dateieigentumerschaft | | | (chown(2), fchownat(2) und | | | verwandte Aufrufe) | +----------------+---------------------------------+ |@clock | Systemaufrufe zur Anderung der | | | Systemuhr (adjtimex(2), | | | settimeofday(2) und verwandte | | | Aufrufe) | +----------------+---------------------------------+ |@cpu-emulation | Systemaufrufe fur | | | CPU-Emulierungsfunktionen | | | (vm86(2) und verwandte Aufrufe) | +----------------+---------------------------------+ |@debug | Fehlersuche, | | | Leistungsuberwachung und | | | Nachverfolgungsfunktionen | | | (ptrace(2), perf_event_open(2) | | | und verwandte Aufrufe) | +----------------+---------------------------------+ |@file-system | Dateisystemaktionen: Offnen, | | | Dateien und Verzeichnisse zum | | | Lesen und Schreiben erstellen, | | | sie umbenennen oder entfernen, | | | Lesen von Dateieigenschaften | | | oder Erstellen von harten und | | | symbolischen Links | +----------------+---------------------------------+ |@io-event | Systemaufrufe fur | | | Ereignisschleifen (poll(2), | | | select(2), epoll(7), eventfd(2) | | | und verwandte Aufrufe) | +----------------+---------------------------------+ |@ipc | Pipes, SysV IPC, | | | POSIX-Nachrichtenwarteschlangen | | | und andere IPC (mq_overview(7), | | | svipc(7)) | +----------------+---------------------------------+ |@keyring | Kernel-Schlusselbundzugriff | | | (keyctl(2) und verwandte | | | Aufrufe) | +----------------+---------------------------------+ |@memlock | Sperren von Speicher im RAM | | | (mlock(2), mlockall(2) und | | | verwandte Aufrufe) | +----------------+---------------------------------+ |@module | Laden und Entladen von | | | Kernelmodulen (init_module(2), | | | delete_module(2) und verwandte | | | Aufrufe) | +----------------+---------------------------------+ |@mount | Einhangen und Aushangen von | | | Dateisystemen (mount(2), | | | chroot(2) und verwandte | | | Aufrufe) | +----------------+---------------------------------+ |@network-io | Socket-E/A (einschliesslich | | | lokalem AF_UNIX): socket(7), | | | unix(7) | +----------------+---------------------------------+ |@obsolete | Ungewohnliches, Veraltetes oder | | | nicht Implementiertes | | | (create_module(2), gtty(2), | | | ) | +----------------+---------------------------------+ |@pkey | Systemaufrufe, die sich um | | | Speicherschutzschlussel | | | (pkeys(7)) kummern | +----------------+---------------------------------+ |@privileged | Alle Systemaufrufe, die | | | Administrator-Capabilities | | | benotigen (capabilities(7)) | +----------------+---------------------------------+ |@process | Prozesssteuerung, -ausfuhrung, | | | Namensraumaktionen (clone(2), | | | kill(2), namespaces(7), ) | +----------------+---------------------------------+ |@raw-io | Rohzugriff auf E/A-Ports | | | (ioperm(2), iopl(2), | | | pciconfig_read(), ) | +----------------+---------------------------------+ |@reboot | Systemaufrufe fur den Neustart | | | und die Neustartvorbereitung | | | (reboot(2), kexec(), ) | +----------------+---------------------------------+ |@resources | Systemaufrufe fur die Anderung | | | von Ressourcenbeschrankungen, | | | Speicher- und | | | Schedulingparametern | | | (setrlimit(2), setpriority(2), | | | ) | +----------------+---------------------------------+ |@sandbox | Systemaufrufe fur | | | sandboxed-Programme | | | (seccomp(2), | | | Landlock-Systemaufrufe, ) | +----------------+---------------------------------+ |@setuid | Systemaufrufe zur Anderung der | | | Benutzerkennung und | | | Gruppenberechtigungen | | | (setuid(2), setgid(2), | | | setresuid(2), ) | +----------------+---------------------------------+ |@signal | Systemaufrufe fur die | | | Veranderung und Handhabung von | | | Prozesssignalen (signal(2), | | | sigprocmask(2), ) | +----------------+---------------------------------+ |@swap | Systemaufrufe fur die | | | Aktivierung/Deaktivierung von | | | Auslagerungsgeraten (swapon(2), | | | swapoff(2)) | +----------------+---------------------------------+ |@sync | Synchronisierung von Dateien | | | und Speicher auf Platte | | | (fsync(2), msync(2) und | | | verwandte Aufrufe) | +----------------+---------------------------------+ |@system-service | Eine vernunftige Gruppe von | | | Systemaufrufen, die von | | | typischen Systemdiensten | | | benutzt werden, ausschliesslich | | | aller Systemaufrufe fur | | | besondere Zwecke. Dies ist der | | | empfohlene Anfangspunkt zum | | | expliziten Erlauben von | | | Systemaufrufen fur | | | Systemdienste, da es das | | | enthalt, was typischerweise von | | | Systemdiensten benotigt wird, | | | aber ausserst spezielle | | | Schnittstellen ausschliesst. | | | Beispielsweise sind die | | | folgenden APIs ausgeschlossen: | | | >>@clock<<, >>@mount<<, | | | >>@swap<<, >>@reboot<<. | +----------------+---------------------------------+ |@timer | Systemaufrufe fur | | | Scheduling-Aktionen von Time | | | (alarm(2), timer_create(2), | | | ) | +----------------+---------------------------------+ |@known | Alle durch den Kernel | | | definierten Systemaufrufe. | | | Diese Liste ist in Systemd | | | statisch basierend auf der | | | Kernelversion, die bei der | | | Veroffentlichung von Systemd | | | verfugbar war, definiert. Sie | | | wird fortschreitend veralten, | | | wenn der Kernel aktualisiert | | | wird. | +----------------+---------------------------------+ Beachten Sie, dass neue Systemaufrufe zu den obigen Gruppen hinzugefugt werden konnten, wenn neue Systemaufrufe zu dem Kernel hinzugefugt werden. Die Inhalte dieser Gruppen konnen sich auch zwischen Systemd-Versionen unterscheiden. Zusatzlich hangt die Liste der Systemaufrufe auch von der Kernelversion und der Architektur, fur die Systemd kompiliert wurde, ab. Verwenden Sie systemd-analyze syscall-filter, um die tatsachliche Liste der Systemaufrufe in jedem Filter aufzufuhren. Im Allgemeinen ist das explizite Erlauben von Systemaufrufen (statt einer Ausschlussliste) der sicherere Betriebsmodus. Es wird empfohlen, fur alle langlaufenden Systemdienste eine Liste explizit erlaubter Systemaufrufe zu erzwingen. Insbesondere sind die nachfolgenden Zeilen eine relativ sicherere grundlegende Wahl fur den Grossteil der Systemdienste: [Service] SystemCallFilter=@system-service SystemCallErrorNumber=EPERM Beachten Sie, dass die verschiedenen Systemaufrufe redundant definiert werden: es gibt mehrere Systemaufrufe zur Ausfuhrung der gleichen Aktion. Beispielsweise kann der Systemaufruf pidfd_send_signal() zur Ausfuhrung von Aktionen ahnlich zu dem alteren Systemaufruf kill() verwandt werden, daher fuhrt das Blockieren von letzterem ohne das Blockieren des ersteren nur zu einem schwachen Schutz. Da neue Systemaufrufe regelmassig dem Kernel hinzugefugt werden, verlangt das Pflegen von vollstandigen Ausschlusslisten fur Systemaufrufe standige Arbeit. Es wird daher empfohlen, stattdessen Freischaltungen einzusetzen, wodurch der Nutzen entsteht, dass neue Systemaufrufe standardmassig implizit blockiert sind, bis die Freischaltung aktualisiert wurde. Beachten Sie auch, dass eine Reihe von Systemaufrufen zugreifbar sein mussen, damit der dynamische Linker funktioniert. Der dynamische Linker wird zur Ausfuhrung der meisten regularen Programme benotigt (konkret dynamische ELF-Programme - auf diese Art bauen die meisten Distributionen paketierte Programme). Dies bedeutet, dass das Blockieren dieser Systemaufrufe (wozu open(), openat() und mmap() gehoren) dazu fuhren wird, das die meisten mit generischen Distributionen ausgelieferten Programme unbenutzbar werden. Es wird empfohlen, die auf den Namensraum des Dateisystems bezogenen Optionen mit SystemCallFilter=~@mount zu kombinieren, um zu verhindern, dass die Prozesse der Unit die Abbildungen ruckgangig machen. Insbesondere sind dies die Optionen PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=, ProtectKernelTunables=, ProtectControlGroups=, ProtectKernelLogs=, ProtectClock=, ReadOnlyPaths=, InaccessiblePaths= und ReadWritePaths=. Hinzugefugt in Version 187. SystemCallErrorNumber= Akzeptiert eine >>errno<<-Fehlernummer (zwischen 1 und 4095) oder einen Errno-Namen wie EPERM, EACCES oder EUCLEAN, der zuruckgeliefert werden soll, wenn der mit SystemCallFilter= konfigurierte Systemaufruffilter ausgelost wird, statt den Prozess sofort zu beenden. Siehe errno(3) fur eine vollstandige Liste der Fehlercodes. Wenn diese Einstellung nicht benutzt wird, oder wenn ihm die leere Zeichenkette oder die besondere Einstellung >>kill<< zugewiesen wird, wird der Prozess sofort beendet, wenn der Filter ausgelost wird. Hinzugefugt in Version 209. SystemCallArchitectures= Akzeptiert eine Leerzeichen-getrennte Liste von Architekturkennungen, die in den Systemaufrufilter einbezogen werden sollen. Die bekannten Architekturkennungen sind die gleichen wie fur das in systemd.unit(5) beschriebene ConditionArchitecture=, sowie x32, mips64-n32, mips64-le-n32 und die besondere Kennung native. Die besondere Kennung native wird implizit auf die native Architektur des Systems abgebildet (oder genauer: auf die Architektur, fur die der Systemverwalter kompiliert wurde). Standardmassig wird diese Option auf die leere Liste gesetzt, d.h. keine Filterung erfolgt. Falls diese Einstellung verwandt wird, wird den Prozessen dieser Unit nur der Aufruf nativer Systemaufrufe und von Systemaufrufen der festgelegten Architektur erlaubt. Fur die Zwecke dieser Option wird die Architektur X32 so behandelt, dass sie die Systemaufrufe von X86-64 enthalt. Allerdings erfullt diese Einstellung auf X32 weiterhin ihren Zweck, wie unten dargestellt. Systemaufruffilterung ist nicht auf allen Architekturen wirksam. Beispielsweise ist auf X86 aufgrund von ABI-Einschrankungen das Filtern von Netz-Socket-bezogenen Aufrufen nicht moglich, eine Einschrankung, die X86-64 allerdings nicht hat. Auf Systemen, die mehrere ABI gleichzeitig unterstutzen, wie X86/X86-64, wird daher empfohlen, die Gruppe der erlaubten Systemaufrufarchitekturen einzuschranken, so dass das sekundare ABI nicht dazu verwandt werden kann, die dem nativen ABI des Systems auferlegten Einschrankungen zu umgehen. Insbesondere ist das Setzen von SystemCallArchitectures=native fur das Deaktivieren nichtnativer ABIs eine gute Wahl. Systemaufrufarchitekturen konnen auch systemweit mittels der Option SystemCallArchitectures= in der globalen Konfiguration eingeschrankt werden. Siehe systemd-system.conf(5) fur Details. Hinzugefugt in Version 209. SystemCallLog= Akzeptiert eine Leerzeichen-getrennte Liste von Systemaufrufenamen. Falls diese Einstellung verwandt wird, werden alle aufgefuhrten Systemaufrufe, die durch die Prozesse der Unit ausgefuhrt werden, protokolliert. Falls das erste Zeichen der Liste >>~<< ist, wird die Wirkung invertiert: alle ausser den aufgefuhrten Systemaufrufen werden protokolliert. Diese Funktionalitat verwendet die Schnittstelle >>Secure Computing Mode 2<< des Kernels (>>Seccomp-Filterung<<) und ist nutzlich, um die Sandboxing-Umgebung zu auditieren oder einzurichten. Diese Option kann mehr als einmal angegeben werden, die Filtermasken werden in diesem Fall zusammengefuhrt. Falls die leere Zeichenkette zugewiesen wird, wird der Filter zuruckgesetzt und alle vorherigen Zuweisungen haben keine Wirkung. Diese betrifft Befehle, denen >>+<< vorangestellt ist, nicht. Hinzugefugt in Version 247. UMGEBUNGSVARIABLEN Environment= Setzt Umgebungsvariablen fur ausgefuhrte Prozesse. Bei jeder Zeile wird der Schutz gemass der im Abschnitt >>Schutzen<< in systemd.syntax(7) beschriebenen Regeln aufgehoben und wird dadurch eine Liste von Variablenzuweisungen. Falls Sie einer Variable einen Wert zuweisen mussen, der Leer- oder Gleichheitszeichen enthalt, umschliessen Sie die gesamte Zuweisung mit englischen Anfuhrungszeichen. Innerhalb der Zeichenketten erfolgt keine Variablenexpandierung und das Zeichen >>$<< hat keine besondere Bedeutung. Kennzeichnerexpandierung wird durchgefuhrt, siehe den Abschnitt >>Kennzeichner<< in systemd.unit(5). Diese Option kann mehr als einmal angegeben werden, dann werden alle aufgefuhrten Variablen gesetzt. Falls die gleiche Option zweimal aufgefuhrt wird, setzt die spatere Einstellung die fruhere Einstellung ausser Kraft. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste der Umgebungsvariablen zuruckgesetzt und alle vorherigen Zuweisungen haben keinen Effekt. Die Namen der Variablen durfen ASCII-Buchstaben, Ziffern und der Unterstrich enthalten sein. Variablennamen durfen nicht leer sein oder mit einer Ziffer beginnen. In den Variablenwerten sind die meisten Zeichen erlaubt, aber nicht darstellbare Zeichen werden derzeit zuruckgewiesen. Beispiel: Environment="VAR1=Wort1 Wort2" VAR2=Wort3 "VAR3=$Wort 5 6" ergibt drei Variablen >>VAR1<<, >>VAR2<<, >>VAR3<< mit den Werten >>Wort1 Wort2<<, >>Wort3<<, >>$Wort 5 6<<. Siehe environ(7) fur Details uber Umgebungsvariablen. Beachten Sie, dass Umgebungsvariablen nicht dazu geeignet sind, Geheimnisse (wie Passworter, Schlusselmaterial, ) an Diensteprozesse weiterzugeben. Fur eine Unit gesetzte Umgebungsvariablen konnen von nicht privilegierten Clients wie D-Bus-IPC eingesehen werden und werden im Allgemeinen nicht als Daten betrachtet, die geschutzt werden mussen. Desweiteren werden Umgebungsvariablen den Prozessbaum heruntergereicht, auch uber Sicherheitsgrenzen (wie Setuid/Setgid-Programme) hinweg und konnten daher zu Prozessen durchsickern, die keinen Zugriff auf die geheimen Daten haben sollen. Verwenden Sie LoadCredential=, LoadCredentialEncrypted= oder SetCredentialEncrypted= (siehe unten), um Daten sicher an Unit-Prozesse zu ubergeben. EnvironmentFile= Ahnlich zu Environment=, liest aber die Umgebungsvariablen aus einer Textdatei. Die Textdatei sollte durch Zeilenumbruche getrennte Variablenzuweisungen enthalten. Leere Zeilen, Zeilen ohne einen >>=<<-Trenner und Zeilen, die mit >>;<< oder >>#<< beginnen, werden ignoriert. Letzteres kann zur Kommentierung verwandt werden. Die Datei muss in UTF-8 kodiert sein. Gultige Werte sind Unicode Skalarwerte[8] ausser Unicode-Nichtzeichen[9], U+0000 NUL und U+FEFF Unicode-Byte-Reihenfolge-Markierung[10]. Steuerzeichen ausser NUL sind erlaubt. In der Datei wird ein Wert nach dem >>=<< ausserhalb von Anfuhrungszeichen mit den gleichen Ruckwarts-Schragstrich-Regeln wie POSIX-Shell-Text ohne Anfuhrungszeichen[11] ausgewertet. Allerdings wird anders als in einer Shell innenliegender Leerraum beibehalten und Anfuhrungszeichen nach dem erste Zeichen, das kein Leerraum ist, werden erhalten. Fuhrende und abschliessende Leerraumzeichen (Leerzeichen, Tabulatoren, Zeilenumbruche) werden verworfen, aber innere Leeraumzeichen innerhalb der Zeile bleiben unverandert erhalten. Eine Zeile, die mit einem Ruckwartsschragstrich endet, wird auf der nachfolgenden weitergefuhrt, wobei der Zeilenumbruch selbst verworfen wird. Ein Ruckwartsschragstrich >>\<< gefolgt von einem Zeichen ausser dem Zeilenumbruch selbst wird das nachfolgende Zeichen erhalten, so dass aus >>\\<< der Wert >>\<< wird. In der Datei kann ein mit >>'<< maskierter Wert nach dem >>=<< uber mehrere Zeilen gehen und jedes Zeichen ausser dem Anfuhrungszeichen selbst direkt enthalten, wie POSIX-Shell-Text in einfachen Anfuhrungszeichen[12]. Es werden keine Ruckwartsschragstrich-Maskiersequenzen erkannt. Fuhrende und abschliessende Leerraumzeichen ausserhlab der einfachen Anfuhrungszeichen werden verworfen. In der Datei kann ein mit >>"<< maskierter Wert nach dem >>=<< uber mehrere Zeilen gehen und die gleichen Maskiersequenzen wie in POSIX-Shell-Text in doppelten englischen Anfuhrungszeichen[13] werden erkannt. Ruckwartsschragstrich (>>\<<) gefolgt von einem aus >>"\`$<< wird das Zeichen erhalten. Ein Ruckwartsschragstrich, dem ein Zeilenumbruch folgt, ist eine Zeilenfortsetzung, und das Zeilenumbruchzeichen selbst wird verworfen. Andere Zeichen, die dem Ruckwartsschragstrich folgen, werden ignoriert; sowohl der Ruckwartsschragstrich als auch das nachfolgende Zeichen werden so erhalten. Fuhrende und abschliessende Leerraumzeichen ausserhalb der doppelten Anfuhrungszeichen werden verworfen. Das ubergebene Argument sollte ein absoluter Dateiname oder ein Platzhalterausdruck sein, dem optional >>-<< vorangestellt werden kann, um anzuzeigen, dass sie nicht gelesen werden soll und keine Fehler- oder Warnmeldung protokolliert wird, falls sie nicht existiert. Diese Option kann mehr als einmal angegeben werden, in diesem Fall werden alle festgelegten Dateien gelesen. Falls der Option die leere Zeichenkette zugewiesen wird, wird die Liste der zu lesenden Dateien zuruckgesetzt und alle vorherigen Zuweisungen haben keine Wirkung. Die mit dieser Anweisung aufgefuhrten Dateien werden kurz vor der Ausfuhrung 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 nachsten lesen konnen. Diese Dateien werden aus dem Dateisystem des Diensteverwalters gelesen, bevor Anderungen im Dateisystem wie Bind-Einhangungen stattfinden). Einstellungen von diesen Dateien setzen mit Environment= vorgenommene Einstellungen ausser Kraft. Falls die gleiche Variable zweimal von diesen Dateien gesetzt wird, werden die Dateien in der festgelegten Reihenfolge eingelesen und spatere Einstellungen werden die fruheren Einstellungen ausser Kraft setzen. PassEnvironment= Ubergibt fur den Diensteverwalter gesetzte Umgebungsvariablen an ausgefuhrte Prozesse. Akzeptiert eine Leerzeichen-getrennte Liste von Variablennamen. Diese Option kann mehr als einmal angegeben werden, dann werden alle aufgefuhrten Variablen ubergeben. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste der zu ubergebenden Umgebungsvariablen zuruckgesetzt, alle vorherigen Zuweisungen haben keine Wirkung. Festgelegte Variablen, die fur den Systemverwalter nicht gesetzt sind, werden nicht ubergeben und werden ohne Ruckmeldung ignoriert. Beachten Sie, dass diese Option nur fur den Systemdiensteverwalter relevant ist, da Systemdienste standardmassig keine Umgebungsvariablen, die fur den Diensteverwalter gesetzt sind, erben. Im Falle des Benutzerdiensteverwalters werden alle Umgebungsvariablen sowieso an den ausgefuhrten Prozess ubergeben, daher hat diese Option fur Benutzerdiensteverwalter keine Wirkung. Variablen, die aufgrund dieser Einstellung fur aufgerufene Prozesse gesetzt werden, konnten durch solche, die mit Environment= oder EnvironmentFile= konfiguriert wurden, ausser Kraft gesetzt zu werden. Beispiel: PassEnvironment=VAR1 VAR2 VAR3 ubergibt die drei Variablen >>VAR1<<, >>VAR2<<, >>VAR3<< mit den fur diese Variablen in PID1 gesetzten Werten. Siehe environ(7) fur Details uber Umgebungsvariablen. Hinzugefugt in Version 228. UnsetEnvironment= Setzt die Variablenzuweisungen, die normalerweise von dem Diensteverwalter an den aufgerufenen Prozess dieser Unit weitergegeben wurden, zuruck. Akzeptiert eine Lerraum-getrennte Liste von Variablennamen oder Variablenzuweisungen. Diese Option kann mehr als einmal angegeben werden, dann werden alle aufgefuhrten Variablen/Zuweisungen zuruckgesetzt. Falls der Option die leere Zeichenkette zugewiesen wird, wird die Liste der Umgebungsvariablen/Zuweisungen, die zuruckgesetzt werden sollen, zuruckgesetzt. Falls eine Variablenzuweisung festgelegt ist (das heisst: einem Variablennamen, dem ein >>=<< und sein Wert folgt), dann wird jede Umgebungsvariable, die exakt auf diese Zuweisung passt, entfernt. Falls ein Variablennname festgelegt ist (das ist ein Variablenname, dem kein >>=<< oder ein Wert folgt), dann wird jede Zuweisung, die auf diesen Variablennamen passt, entfernt, unabhangig von dessen Wert. Beachten Sie, dass die Wirkung von UnsetEnvironment= als abschliessender Schritt angewandt wird, wenn die an den auszufuhrenden Prozess zu ubergebende Umgebungsliste zusammengestellt wird. Das bedeutet, dass es Zuweisungen von jeder Konfigurationsquelle ruckgangig machen konnte, einschliesslich Zuweisungen, die mittels Environment= oder EnvironmentFile= erfolgten, die von der globalen Menge der Umgebungsvariablen des Systemverwalters geerbt wurden, die vom Diensteverwalter selbst gesetzt wurden (wie $NOTIFY_SOCKET und ahnliche) oder die durch ein PAM-Modul gesetzt wurden (falls PAMName= benutzt wird). Siehe nachfolgenden Abschnitt >>Umgebungsvariablen in erzeugten Prozessen<< fur eine Beschreibung, wie diese Einstellungen kombiniert werden, um eine vererbte Umgebung zu bilden. Siehe environ(7) fur allgemeine Informationen uber Umgebungsvariablen. Hinzugefugt in Version 235. PROTOKOLLIERUNG UND STANDARD-EIN-/-AUSGABE StandardInput= Steuert, womit der Dateideskriptor 0 (STDIN) des ausgefuhrten Prozesses verbunden ist. Akzeptiert null, tty, tty-force, tty-fail, data, file:Pfad, socket oder fd:Name. Falls null ausgewahlt wird, wird die Standardeingabe mit /dev/null verbunden, d.h. alle Leseversuche durch den Prozess werden sofort zu einem EOF fuhren. Falls tty ausgewahlt ist, wird die Standardeingabe mit einem TTY (wie mit TTYPath= konfiguriert, siehe unten) verbunden und der ausgefuhrte Prozess wird der steuernde Prozess des Terminals. Falls das Terminal bereits durch einen anderen Prozess gesteuert wird, wartet der ausgefuhrte Prozess, bis der derzeit steuernde Prozess das Terminal freigibt. tty-force ist ahnlich zu tty, der ausgefuhrte Prozess wird aber zwangsweise und sofort zum steuernden Prozess des Terminals gemacht, moglicherweise werden dabei vorhergehende steuernde Prozesse von dem Terminal entfernt. tty-fail ist ahnlich zu tty, falls aber das Terminal bereits einen steuernden Prozess hat, schlagt das Hochfahren des ausgefuhrten Prozesses fehl. Die Option data kann zur Konfiguration beliebiger textueller oder binarer Daten, die mittels Standardeingabe an den ausgefuhrten Prozess ubergeben werden sollen, verwandt werden. Die zu ubergebenden Daten werden mittels StandardInputText=/StandardInputData= (siehe unten) konfiguriert. Beachten Sie, dass der tatsachlich ubergebene Dateideskriptortyp (Speicherdatei, regulare Datei, UNIX-Pipe, ) vom Kernel und den verfugbaren Privilegien abhangen konnte. Auf jeden Fall ist der Dateideskriptor nur lesbar und er liefert die festgelegten Daten, gefolgt von EOF, zuruck, wenn er gelesen wird. Die Option file:Pfad kann zur Verbindung der Standardeingabe mit einem bestimmten Dateisystemobjekt verwandt werden. Es wird ein absoluter Pfad gefolgt von dem Zeichen >>:<< erwartet, der sich auf eine regulare Datei, ein FIFO oder eine Spezialdatei beziehen kann. Falls ein AF_UNIX-Socket in dem Dateisystem festgelegt ist, wird mit ihm ein Datenstrom-Socket verbunden. Letzteres ist nutzlich, um die Standardeingabe eines beliebigen Prozesses mit einem beliebigen Systemdienst zu verbinden. Die Option >>socket<< ist nur in Socket-aktivierten Diensten gultig und es muss in der relevanten Socket-Unit-Datei (siehe systemd.socket(5) fur Details) Accept=yes gesetzt oder nur ein einzelnes Socket spezifiziert sein. Falls diese Option gesetzt ist, wird die Standardeingabe mit dem Socket, aus dem der Dienst aktiviert wurde, verbunden. Dies ist hauptsachlich fur die Kompatibilitat mit Daemons nutzlich, die fur die Verwendung mit der traditionellen inetd(8)-Socket-Daemon-Aktivierung entwickelt wurden (Umgebungsvariablen $LISTEN_FDS (und verwandte) werden nicht weitergegeben, wenn der Wert socket konfiguriert ist). Die Option fd:Name verbindet die Standardeingabe mit einem durch die Socket-Unit bereitgestellten bestimmten, benannten Dateideskriptor. Der Name kann als Teil dieser Option angegeben werden, gefolgt vom Zeichen >>:<< (z.B. >>fd:foobar<<). Falls kein Name angegeben ist, wird der Name >>stdin<< impliziert (d.h. >>fd<< ist aquivalent zu >>fd:stdin<<). Mindestens eine Socket-Unit, die den angegebenen Namen definiert, muss uber die Option Sockets= bereitgestellt werden und der Dateideskriptorname darf sich vom Namen der Socket-Unit, die ihn enthalt, unterscheiden. Falls mehrere Treffer gefunden werden, wird der erste verwandt. Siehe FileDescriptorName= in systemd.socket(5) fur weitere Details uber benannte Dateideskriptoren und ihrer Sortierung. Diese Einstellung ist standardmassig null, ausser StandardInputText=/StandardInputData= sind gesetzt, dann ist die Vorgabe data. StandardOutput= Steuert, womit der Dateideskriptor 1 (Stdout) des ausgefuhrten Prozesses verbunden ist. Akzeptiert entweder inherit, null, tty, journal, kmsg, journal+console, kmsg+console, file:Pfad, append:Pfad, truncate:Pfad, socket oder fd:Name. inherit dupliziert den Dateideskriptor der Standardeingabe fur die Standardausgabe. null verbindet die Standardausgabe mit /dev/null, d.h. alles dahin Geschriebene geht verloren. tty verbindet die Standardausgabe mit einem TTY (wie in TTYPath= konfiguriert, siehe unten). Falls das TTY nur fur die Ausgabe verwandt wird, wird der ausgefuhrte Prozess nicht der steuernde Prozess des Terminals werden und wird nicht fehlschlagen oder darauf warten, dass andere Prozesse das Terminal freigeben. journal verbindet die Standardausgabe mit dem Journal, das uber journalctl(1) erreichbar ist. Beachten Sie, dass alles, was nach Syslog oder Kmsg (siehe unten) geschrieben wird, implizit auch im Journal gespeichert wird, die spezielle unten aufgefuhrten Optionen ist daher eine Obermenge dieser Option. (Beachten Sie auch, dass alle externen, zusatzlichen Syslog-Daemons ihre Protokolldaten auch aus dem Journal empfangen, daher ist dies die Option, die verwandt werden sollte, wenn das Protokoll mit solch einem Daemon verarbeitet werden soll.) kmsg verbindet die Standardeingabe mit dem Kernelprotokollpuffer, der uber dmesg(1) erreichbar ist, zusatzlich zum Journal. Der Journal-Daemon konnte so konfiguriert sein, dass er alles, was er empfangt, sowieso zu Kmsg sendet, wodurch diese Option in diesem Fall keinen Unterschied zu journal darstellt. journal+console und kmsg+console arbeiten auf eine ahnliche Art wie die zwei Optionen oben, kopieren aber auch samtliche Ausgabe auf die Systemkonsole. Die Option file:Pfad kann zum Verbinden eines bestimmten Dateisystemobjektes mit der Standardausgabe verwandt werden. Die Semantik ist ahnlich zu der der gleichen Option von StandardInput=, siehe oben. Falls sich Pfad auf eine regulare Datei auf dem Dateisystem bezieht, wird sie zum Schreiben am Anfang der Datei geoffnet (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 - geoffnet und dupliziert. Dies ist insbesondere nutzlich, wenn sich der festgelegte Pfad auf ein AF_UNIX-Socket im Dateisystem bezieht, da in diesem Fall nur eine einzelne Datenstromverbindung fur sowohl Ein- als auch Ausgabe erstellt wird. append:Pfad ist ahnlich zu file:Pfad oben, es offnet die Datei aber im Anhangemodus. truncate:Pfad ist ahnlich zu obigem file:Pfad, schneidet die Datei beim Offnen aber ab. Fur Units mit mehreren Befehlszeilen, z.B. Type=oneshot-Dienste mit mehreren ExecStart= oder Diensten mit ExecCondition=, ExecStartPre= oder ExecStartPost=, wird die Ausgabedatei erneut fur jede Befehlszeile geoffnet und daher erneut abgeschnitten. Falls die Ausgabedatei abgeschnitten wird, wahrend ein anderer Prozess die Datei noch geoffnet hat, z.B. durch ein ExecReload=, das parallel zu einem ExecStart= ausgefuhrt wird, und dieser Prozess weiter in die Datei schreibt, ohne seinen Versatz anzupassen, dann kann der Leerraum zwischen den Dateizeigern der zwei Prozesse mit Nullbytes (NUL) aufgefullt werden, wodurch eine Sparse-Datei erzeugt wird. Daher ist truncate:Pfad normalerweise nur mit einer einzelnen ExecStart= und keinem ExecStartPost=, ExecReload=, ExecStop= oder ahnlichem nutzlich. socket verbindet die Standardausgabe zu einem mittels Socket-Aktivierung erlangten Socket. Die Semantik ist ahnlich zu der der gleichen Option von StandardInput=, siehe oben. Die Option fd:Name verbindet die Standardausgabe mit einem bestimmten benannten, durch eine Socket-Unit bereitgestellten Dateideskriptor. Es kann als Teil dieser Option ein Name, gefolgt von einem >>:<<-Zeichen, angegeben werden (z.B. >>fd:foobar<<). Falls kein Name angegeben ist, wird der Name >>stdout<< impliziert (d.h. >>fd<< ist aquivalent zu >>fd:stdout<<). Mindestens eine Socket-Unit, die den angegebenen Namen definiert, muss uber die Option Sockets= bereitgestellt werden und der Dateideskriptorname darf sich vom Namen der Socket-Unit, die ihn enthalt, unterscheiden. Falls mehrere Treffer gefunden werden, wird der erste verwandt. Siehe FileDescriptorName= in systemd.socket(5) fur weitere Details uber benannte Dateideskriptoren und ihrer Sortierung. Falls die Standardausgabe (oder die Fehlerausgabe, siehe unten) einer Unit mit dem Journal oder dem Kernelprotokollpuffer verbunden ist, wird die Unit implizit eine Abhangigkeit vom Typ After= von systemd-journald.socket erhalten (siehe auch den Abschnitt >>Implizite Abhangigkeiten<< oben). Beachten Sie auch, dass in diesem Fall Stdout (oder Stderr, siehe unten) ein AF_UNIX-Datenstrom-Socket und keine PIPE oder FIFO, die erneut geoffnet werden kann, sein wird. Das bedeutet, dass bei der Ausfuhrung von Shell-Skripten die Konstruktion >>echo "hello" > /dev/stderr<< zum Schreiben von Text nach Stderr nicht funktionieren wird. Um dies zu entscharfen, verwenden Sie stattdessen die Konstruktion >>echo "hello" >&2<<, die grosstenteils aquivalent ist und diesen Fallstrick vermeidet. Falls StandardInput= auf entweder tty, tty-force, tty-fail, socket oder fd:Name gesetzt ist, die die Vorgabe fur diese Einstellung inherit. In anderen Fallen ist der Vorgabewert dieser Einstellung der mit DefaultStandardOutput= in systemd-system.conf(5) gesetzte Wert, der standardmassig journal ist. Beachten Sie, dass dieser Parameter zum Hinzufugen zusatzlicher Abhangigkeiten fuhren kann (siehe oben). StandardError= Steuert, womit Dateideskriptor 2 (Stderr) des ausgefuhrten Prozesses verbunden ist. Die verfugbaren Optionen sind identisch zu denen von StandardOutput= mit einigen Ausnahmen: falls auf inherit gesetzt, wird der fur die Standardausgabe verwandte Dateideskriptor fur die Standardfehlerausgabe dupliziert, wahrend fd:Name den vorgegebenen Dateideskriptornamen von >>stderr<< verwenden wird. Der Vorgabewert dieser Einstellung ist der mit DefaultStandardError= in systemd-system.conf(5) gesetzte Wert, der standardmassig inherit ist. Beachten Sie, dass dieser Parameter zum Hinzufugen zusatzlicher Abhangigkeiten fuhren kann (siehe oben). StandardInputText=, StandardInputData= Konfiguriert beliebige textuelle oder binare Daten, die mittels Dateideskriptor 0 (STDIN) an den ausgefuhrten Prozess ubergeben werden sollen. Diese Einstellung hat keine Wirkung, ausser StandardInput= ist auf data gesetzt (dies ist die Vorgabe, falls StandardInput= nicht anderweitig gesetzt ist, aber StandardInputText=/StandardInputData= verwandt wird). Verwenden Sie diese Option, um Prozesseingabedaten direkt in die Unit-Datei einzubetten. StandardInputText= akzeptiert beliebige textuelle Daten. C-artige Maskierungen fur besondere Zeichen sowie die normalen >>%<<-Kennzeichner werden aufgelost. Jedes Mal, wenn diese Einstellung benutzt wird, wird der festgelegte Text an den Unit-bezogenen Datenpuffer, gefolgt von einem Zeilenumbruchzeichen, angehangt (daher hangt jeder Einsatz eine neue Zeile an das Ende des Puffers an). Beachten Sie, dass einleitende und abschliessende Leerraumzeichen von mit dieser Option konfigurierten Zeilen entfernt werden. Falls eine leere Zeile festgelegt wird, wird der Puffer bereinigt (daher sollte ein zusatzliches >>\n<< an das Ende oder den Anfang einer Zeile eingefugt werden, um eine leere Zeile einzufugen). StandardInputData= akzeptiert beliebige, in Base64[14] kodierte binare Daten. Es werden keine Maskiersequenzen oder Kennzeichner aufgelost. Samtliche Leerraumzeichen in der kodierten Version werden wahrend der Dekodierung ignoriert. Beachten Sie, dass StandardInputText= und StandardInputData= auf dem gleichen Datenpuffer arbeiten und gemischt werden konnen, um sowohl binare als auch textuelle Daten fur den gleichen Eingabedatenstrom zu konfigurieren. Die textuellen oder binaren Daten werden genau in der Reihenfolge zusammengefugt, in der sie in der Unit-Datei auftauchen. Wird einem eine leere Zeichenkette zugewiesen, wird der Datenpuffer zuruckgesetzt. Bitte beachten Sie, dass lange Unit-Dateieinstellungen in mehrere Zeilen aufgeteilt werden konnen, um die Lesbarkeit zu erhalten. Hierzu wird jeder Zeile (ausser der letzten) ein Zeichen >>\<< vorangestellt (siehe systemd.unit(5) fur Details). Dies ist insbesondere fur grosse Daten, die mit diesen Optionen konfiguriert werden, nutzlich. Beispiel: StandardInput=data StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZXMgYW5kIHNvIGRv \ IEkKQSBmdWxsIGNvbW1pdG1lbnQncyB3aGF0IEnigLJtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4n \ dCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJ \ J20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCgpOZXZlciBnb25uYSBnaXZlIHlv \ dSB1cApOZXZlciBnb25uYSBsZXQgeW91IGRvd24KTmV2ZXIgZ29ubmEgcnVuIGFyb3VuZCBhbmQg \ ZGVzZXJ0IHlvdQpOZXZlciBnb25uYSBtYWtlIHlvdSBjcnkKTmV2ZXIgZ29ubmEgc2F5IGdvb2Ri \ eWUKTmV2ZXIgZ29ubmEgdGVsbCBhIGxpZSBhbmQgaHVydCB5b3UK Hinzugefugt in Version 236. LogLevelMax= Konfiguriert eine Filterung gemass Protokollierstufe der durch diese Unit erstellten Protokollnachrichten. Akzeptiert eine syslog-Protokollstufe, entweder emerg (niedrigste Protokollierstufe, nur Nachrichten hochster Prioritat), alert, crit, err, warning, notice, info oder debug (hochste Protokollierstufe, auch Nachrichten niedrigster Prioritat). Siehe syslog(3) fur Details. Standardmassig wird keine Filterung angewandt (d.h. die maximale Protokollierstufe ist standardmassig debug). Verwenden Sie diese Option, um das Protokolliersystem zu konfigurieren, damit es Protokollnachrichten eines bestimmten Dienstes oberhalb der festgelegten Stufe verwirft. Setzen Sie beispielsweise LogLevelMax=info, um die Fehlersuchprotokollierung eines bestimmten, gesprachigen Dienstes auszuschalten. Beachten Sie, dass die konfigurierte Stufe auf alle versandten Protokollnachrichten aller zu diesem Dienst gehorenden Prozesse sowie allen vom Systemverwalterprozess (PID 1) geschriebenen Protokollnachrichten mit Referenz auf diese Unit auf allen unterstutzten Protokollierungsprotokollen angewandt wird. Die Filterung erfolgt fruhzeitig in der Protokollierungspipeline, bevor jegliche Art weiterer Verarbeitung erfolgt. Desweiteren konnten Nachrichten, die erfolgreich durch diesen Filter kommen, dennoch durch angewandte Filter in einer spateren Stufe im Protokollierungsuntersystem verworfen werden. Beispielsweise konnte ein in journald.conf(5) konfiguriertes MaxLevelStore= verbieten, Nachrichten von hoheren Protokollierstufen auf Platte zu speichen, selbst wenn das Unit-bezogene LogLevelMax= die Verarbeitung erlaubte. Hinzugefugt in Version 236. LogExtraFields= Konfiguriert zusatzliche Protokollmetadatenfelder, die in alle Protokolldatensatze aufgenommen werden, die von Prozessen, die dieser Unit zugeordnet sind (einschliesslich Systemd), erstellt werden. Diese Einstellung akzeptiert eine oder mehrere Journal-Feldzuweisungen im Format >>FELD=WERT<<, getrennt durch Leerraumzeichen. Siehe systemd.journal-fields(7) fur Details zum Journal-Feldkonzept. Obwohl die zugrundeliegende Journal-Implementierung binare Feldnamen erlaubt, akzeptiert diese Einstellung nur gultige UTF-8-Werte. Um Leerzeichen in einem Journal-Feldwert aufzunehmen, schliessen Sie die Zuweisung in doppelte Anfuhrungszeichen (") ein. Die normalen Kennzeichner werden in allen Zuweisungen expandiert (siehe unten). Beachten Sie, dass diese Einstellung nicht nur fur das Anhangen von zusatzlichen Metadaten an Protokolldatensatzen einer Unit nutzlich ist. Da alle Felder und Werte indiziert sind, kann dies auch fur Unit-ubergreifenden Protokolldatensatzabgleich verwandt werden. Wird eine leere Zeichenkette zugewiesen, wird die Liste zuruckgesetzt. Beachten Sie, dass diese Funktionalitat derzeit nur fur Systemdienste verfugbar ist, nicht fur benutzerbezogene Dienste. Hinzugefugt in Version 236. LogRateLimitIntervalSec=, LogRateLimitBurst= Konfiguriert die Ratenbegrenzung, die auf von dieser Unit erstellte Protokollnachrichten angewandt wird. Falls in dem durch LogRateLimitIntervalSec= definierten Intervall mehr als in LogRateLimitBurst= festgelegte Nachrichten durch den Dienst protokolliert werden, werden alle weiteren Nachrichten in dem Intervall verworfen, bis das Intervall voruber ist. Es wird eine Meldung uber die verworfenen Nachrichten erstellt. Die Zeitspezifikation fur LogRateLimitIntervalSec= kann in einer der folgenden Einheiten erfolgen: >>s<<, >>min<<, >>h<<, >>ms<<, >>us<<. Siehe systemd.time(7) fur Details. Die Voreinstellungen erfolgen durch die in journald.conf(5) konfigurierten RateLimitIntervalSec= und RateLimitBurst=. Beachten Sie, dass das nur auf Protokollnachrichten angewandt wird, die vom Protokollsubsystem verarbeitet werden, d.h. durch systemd-journald.service(8). Das bedeutet, dass die Ratenbegrenzung nicht angewandt werden, falls Sie Stderr eines Dienstes uber StandardOutput=file: oder einer ahnlichen Einstellung direkt mit einer Datei verbinden (aber sie wird fur mittels syslog(3) oder ahnlichen Funktionen erstellten Meldungen durchgesetzt). Hinzugefugt in Version 240. LogFilterPatterns= Definiert einen erweiterten regularen Ausdruck, um Protokollmeldungen basierend auf dem Feld MESSAGE= der strukturierten Nachricht zu filtern. Falls das erste Zeichen des Musters >>~<< ist, sollen Protokollnachrichten, die auf das Muster passen, verworfen werden. Diese Option akzeptiert ein einzelnes Muster als Argument, kann aber mehrfach verwandt werden, um eine Liste der erlaubten und verbotenen Muster zu erstellen. Falls die leere Zeichenkette zugewiesen wird, wird der Filter zuruckgesetzt und alle vorherigen Zuweisungen haben keine Auswirkung. Da das Zeichen >>~<< zur Definition von Verbotsmuster verwandt wird, muss es durch >>\x7e<< ersetzt werden, um Nachrichten zu erlauben, die mit >>~<< beginnen. Beispielsweise wurde >>~foobar<< ein Muster hinzufugen, das >>foobar<< zu der Verbotsliste hinzufugt, wahrend >>\x7efoobar<< ein Muster, das auf >>~foobar<< passt, zu der Erlaubt-Liste hinzufugt. Protokollmeldungen werden gegen Verbotsmuster gepruft (falls vorhanden), dann gegen Erlaubt-Muster (falls vorhanden). Falls eine Protokollmeldung auf eines der Verbotsmuster passst, wird sie verworfen, unabhangig von den Erlaubt-Mustern. Dann werden die verbliebenen Protokollmeldungen gegen die Erlaubt-Muster gepruft. Meldungen, die auf keines der Erlaubt-Muster passen, werden verworfen. Falls keine Erlaubt-Muster definiert sind, dann werden alle Meldungen direkt verarbeitet, nachdem sie durch die Verbotsfilter gelaufen sind. Filterung basiert auf der Unit, fur die LogFilterPatterns= definiert ist. Das bedeutet, dass von systemd(1) stammende Protokollmeldungen uber die Unit nicht berucksichtigt werden. Gefilterte Protokollmeldungen werden nicht zu traditionellen Syslog-Daemons, dem Kernelprotokollpuffer (kmsg), der Systemd-Konsole weitergeleitet oder als Wall-Meldungen an alle angemeldeten Benutzer gesandt. Beachten Sie, dass diese Funktionalitat derzeit nur fur Systemdienste verfugbar ist, nicht fur benutzerbezogene Dienste. Hinzugefugt in Version 253. LogNamespace= Fuhrt die Prozesse der Unit in dem angegebenen Journal-Namensraum aus. Erwartet eine kurze, benutzerdefinierte Zeichenkette, die den Namensraum kennzeichnet. Falls nicht verwandt, werden die Prozesse des Dienstes im Vorgabe-Journal-Namensraum ausgefuhrt, d.h. ihr Protokolldatenstrom wird durch systemd-journald.service gesammelt und verarbeitet. Falls diese Option verwandt wird, werden samtliche von Prozessen dieser Unit erstellte Protokolldaten (unabhangig, ob diese mittels syslog(), nativer Journal-Protokollierung oder Stdout/Stderr-Protokollierung erfolgen) durch eine Instanz der Vorlagen-Unit systemd-journald@.service gesammelt und verarbeitet, die den festgelegten Namensraum verwaltet. Die Protokolldaten werden ein einem Datenspeicher gelagert, der unabhangig vom Datenspeicher des Vorgabe-Protokoll-Namensraums ist. Siehe systemd-journald.service(8) fur Details uber Journal-Namensraume. Intern sind Journal-Namensraume mittes Linux-Einhangenamensraume und durch Ubereinhangen des Verzeichnisses, das die relevanten AF_UNIX-Sockets fur das Protokollieren in dem Einhangenamensraum enthalt, implementiert. Da Einhangenamensraume verwandt werden, trennt diese Einstellung die Weiterleitung von Einhangungen von den Prozessen der Unit zu dem Rechner ab, ahnlich wie ReadOnlyPaths= und ahnliche oben beschriebene Einstellungen funktionieren. Journal-Namensraume konnen daher nicht fur Dienste verwandt werden, die Einhangepunkte auf dem Rechner etablieren mussen. Wenn diese Option gesetzt ist, wird die Unit automatisch Ordnungs- und Anforderungsabhangigkeiten von den zwei der systemd-journald@.service-Instanz zugeordneten Socket-Units erlangen, so dass diese vor dem Starten der Unit automatisch etabliert werden. Beachten Sie, dass bei Verwendung dieser Option die Protokollierausgabe dieses Dienstes nicht in der regularen journalctl(1)-Ausgabe erscheint, ausser die Option --namespace= wird verwandt. Diese Option ist nur fur Systemdienste verfugbar und wird nicht fur Dienste unterstutzt, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. Hinzugefugt in Version 245. SyslogIdentifier= Setzt den Prozessnamen (>>syslog-Markierung<<), der allen an das Protokollierungssystem oder den Kernelpuffer gesandten langen Zeilen vorangestellt werden soll. Falls nicht gesetzt, ist die Vorgabe der Prozessname des ausgefuhrten Prozesses. Diese Option ist nur nutzlich, wenn StandardOutput= oder StandardError= auf journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit +console). Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden, angewandt. SyslogFacility= Setzt den syslog-Einrichtungskennzeichner, der beim Protokollieren verwandt werden soll. Entweder kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, authpriv, ftp, local0, local1, local2, local3, local4, local5, local6 oder local7. Siehe syslog(3) fur Details. Diese Option ist nur nutzlich, wenn StandardOutput= oder StandardError= auf journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit +console). Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden, angewandt. Standardmassig daemon. SyslogLevel= Die Vorgabe-syslog-Protokollierstufe, die beim Protokollieren zum Protokollierungssystem oder Kernelprotokollpuffer verwandt werden soll. Entweder emerg, alert, crit, err, warning, notice, info oder debug. Siehe syslog(3) fur Details. Diese Option ist nur nutzlich, wenn StandardOutput= oder StandardError= auf journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit +console). Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden, angewandt. Beachten Sie, dass individuellen Zeilen, die von ausgefuhrten Prozessen ausgegeben werden, eine andere Protokollierungsstufe vorangestellt werden kann, die dazu verwandt werden kann, die hier festgelegte Vorgabeprotokollstufe ausser Kraft zu setzen. Die Auswertung dieser vorangestellten Werte kann mit SyslogLevelPrefix= deaktiviert werden, siehe unten. Fur Details siehe sd-daemon(3). Standardmassig info. SyslogLevelPrefix= Akzeptiert ein logisches Argument. Falls wahr und StandardOutput= oder StandardError= auf journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit +console), wird Protokollzeilen, die durch die ausgefuhrten 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 unverandert weitergegeben. Dies gilt nur fur Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden. Fur Details bezuglich des Voranstellens siehe sd-daemon(3). Standardmassig wahr. TTYPath= Setzt den zu verwendenden Terminalgerateknoten, falls die Standardeingabe, -ausgabe oder -fehlerausgabe mit einem TTY verbunden ist (siehe oben). Standardmassig /dev/console. TTYReset= Setzt das mit TTYPath= festgelegte Terminalgerat vor und nach der Ausfuhrung zuruck. Standardmassig >>no<<. TTYVHangup= Trennt alle Clients, die das mit TTYPath= festgelegte Terminalgerat vor und nach der Ausfuhrung geoffnet haben. Standardmassig >>no<<. TTYRows=, TTYColumns= Konfiguriert die Grosse des mit TTYPath= festgelegten TTYs. Falls nicht oder auf die leere Zeichenkette gesetzt, wird die Vorgabe des Kernels verwandt. Hinzugefugt in Version 250. TTYVTDisallocate= Falls das mit TTYPath= festgelegte Terminalgerat ein virtuelles Konsolenterminal ist, wird vor und nach der Ausfuhrung versucht, die Zuordnung aufzuheben. Dies sorgt dafur, dass der Bildschirm und der Scrollback-Puffer (Puffer mit vorherigen Ein-/Ausgaben) geloscht werden. Standardmassig >>no<<. ZUGANGSDATEN LoadCredential=KENNUNG[:PFAD], LoadCredentialEncrypted=KENNUNG[:PFAD] Ubergibt ein Zugangsberechtigungsdatum an die Unit. Zugangsberechtigungsdaten sind binare oder textuelle Objekte begrenzter Grosse, die an Prozesse von Units ubergeben werden konnen. Sie werden hauptsachlich zur Weitergabe kryptographischer Schlussel (sowohl offentlicher als auch privater) oder Zertifikaten, Benutzerkontoinformationen oder Identitatsinformationen vom Rechner an Dienste verwandt. Von den Prozessen der Unit kann auf diese Daten mittels des Dateisystems zugegriffen werden, an einem rein lesbaren Ort der (falls moglich und erlaubt) durch Speicher, der nicht ausgelagert werden darf, hinterlegt ist. Auf die Daten kann nur durch den Benutzer, der der Unit uber die Einstellung User=/DynamicUser= zugeordnet ist, zugegriffen werden (sowie dem Systemverwalter). Wenn verfugbar, wird der Ort der Zugangsberechtigungsdaten in der Umgebungsvariable $CREDENTIALS_DIRECTORY fur die Prozesse der Unit exportiert. Die Einstellung LoadCredential= akzeptiert eine textuelle Kennung als Namen fur ein Zugangsberechtigungsdatum sowie einen Dateisystempfad, getrennt durch einen Doppelpunkt. Die Kennung muss eine kurze ASCII-Zeichenkette sein, die als Dateiname in dem Dateisystem geeignet ist, und kann vom Benutzer frei gewahlt werden. Falls der angegebene Pfad absolut ist, wird er als regulare Datei geoffnet und das Zugangsberechtigungsdatum wird daraus gelesen. Falls sich der absolute Pfad auf ein AF_UNIX-Datenstrom-Socket im Dateisystem bezieht, dann wird zu ihm eine Verbindung aufgebaut (nur einmalig wahrend des Startens) und das Zugangsberechtigungsdatum aus dieser Verbindung ausgelesen, wodurch ein einfacher IPC-Integrationspunkt bereitgestellt wird, um Zugangsberechtigungsdaten dynamisch von anderen Diensten zu ubertragen. Falls der angegeben Pfad nicht absolut ist und selbst wieder als gultiger Zugangsberechtigungsdatumkennzeichner geeignet ist, wird versucht, ein Zugangsberechtigungsdatum zu finden, das der Diensteverwalter selbst unter dem festgelegten Namen empfangen hat - was zur Weiterleitung von Zugangsberechtigungsdaten von einer aufrufenden Umgebung (z.B. einem Container-Verwalter, der den Diensteverwalter aufgerufen hat) an einen Dienst verwandt werden kann. Falls keine passenden Systemzugangsdaten gefunden wurden, werden die Verzeichnisse /etc/credstore/, /run/credstore/ und /usr/lib/credstore/ nach Dateien unter dem Namen der Zugangsberechtigung durchsucht - dies sind daher die bevorzugten Orte fur Zugangsberechtigungsdaten auf der Platte. Falls LoadCredentialEncrypted= verwandt wird, dann werden auch /run/credstore.encrypted/, /etc/credstore.encrypted/ und /usr/lib/credstore.encrypted/ durchsucht. Falls der Dateisystempfad nicht angegeben wird, wird er als identisch zum Zugangsberechtigungsnamen angenommen, d.h. dies ist eine bundige Art und Weise, um zu erklaren, dass Zugangsberechtigungsdaten vom Diensteverwalter in einen Dienst vererbt werden. Diese Option kann mehrfach verwandt werden, wobei jedes Mal ein zusatzliches Zugangsberechtigungsdatum definiert wird, das an die Unit ubergeben wird. Falls ein absoluter Pfad festgelegt wird, der sich auf ein Verzeichnis bezieht, dann wird jede Datei in diesem Verzeichnis (rekursiv) als eine seperate Zugangsberechtigung geladen. Die Kennung fur jede Zugangsberechtigung wird die bereitgestellte Kennung sein, der >>_$FILENAME<< angehangt wird (z.B. >>Key_file1<<). Beim Laden aus einem Verzeichnis werden Symlinks ignoriert. Der Inhalt der Datei/des Sockets konnen beliebige binare oder textuelle Daten sein, einschliesslich Zeilenumbruchzeichen und Nullbytes (NUL). Die Einstellung LoadCredentialEncrypted= ist identisch zu LoadCredential=, ausser das die Zugangsberechtigungsdaten vor der Weitergabe an den ausgefuhrten Prozess entschlusselt und authentifiziert werden. Insbesondere sollte sich der referenzierte Pfad auf eine Datei oder ein Socket mit einer verschlusselten Zugangsberechtigung beziehen, wie das von systemd-creds(1) implementiert wird. Diese Zugangsberechtigung wird geladen, entschlusselt, authentifiziert und dann an die Anwendung in Klartextform weitergegeben, wie das auch bei einer mittels LoadCredential= festgelegten regularen Zugangsberechtigung gemacht wurde. Eine auf diese Weise konfigurierte Zugangsberechtigung kann symmetrisch mit einem geheimen Schlussel verschlusselt/authentifiziert sein, der vom TPM2-Sicherheits-Chip des Systems abgeleitet wurde oder mit einem geheimen Schlussel, der in /var/lib/systemd/credentials.secret gespeichert wird, oder mit beidem. Die Verwendung von verschlusselten und authentifizierten Zugangsberechtigungen erhoht die Sicherheit, da Zugangsberechtigungen nicht im Klartext gespeichert werden und nur zu dem Zeitpunkt authentifiziert und in Klartext entschlusselt werden, zu dem der Dienst, der sie benotigt, gestartet wird. Desweiteren konnten die Zugangsberechtigungen an die lokale Hardware und Installation gebunden werden, so dass sie nicht so leicht vom System getrennt analysiert oder extern erstellt werden konnen. Wenn DevicePolicy= auf >>closed<< oder >>strict<< gesetzt ist oder wenn sie auf >>auto<< gesetzt und DeviceAllow= gesetzt ist oder wenn PrivateDevices= gesetzt ist, dann fugt diese Einstellung /dev/tpmrm0 mit dem Modus rw zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) fur Details uber DevicePolicy= oder DeviceAllow=. Der Diensteverwalter muss auf die Zugangsberechtigungs-Dateien/-Sockets zugreifen konnen, aber die Prozesse musse nicht direkt darauf zugreifen konnen: die Zugangsberechtigungsdaten werden gelesen und getrennte, nur lesbare Kopien fur die Unit werden angelegt, die von den geeignet privilegierten Prozessen gelesen werden konnen. Dies ist insbesondere in Kombination mit DynamicUser= nutzlich, da auf diese Art privilegierte Daten fur Prozesse zur Verfugung gestellt werden konnen, die unter einer dynamischen UID laufen (d.h. einer bisher nicht bekannten), ohne den Zugriff fur alle Benutzer zu eroffnen. Um innerhalb einer ExecStart=-Befehlszeile den Pfad zu referenzieren, unter dem eine Zugangsberechtigung gelesen werden kann, verwenden Sie >>${CREDENTIALS_DIRECTORY}/mycred<<, z.B. >>ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred<<. Um innerhalb einer Environment=-Zeile den Pfad zu referenzieren, unter dem eine Zugangsberechtigung gelesen werden kann, verwenden Sie >>%d/mycred<<, z.B. >>Environment=MYCREDPATH=%d/mycred<<. Fur Systemdienste kann der Pfad auch als >>/run/credentials/UNITNAME<< referenziert werden, wenn keine Interpolation moglich ist, d.h. die Konfigurationsdateien der Software Zugangsberechtigungen noch nicht nativ unterstutzen. $CREDENTIALS_DIRECTORY wird allerdings als die Hauptschnittstelle zur Suche nach Zugangsberechtigungen betrachtet, da es auch fur Benutzerdienste funktioniert. Derzeit wird eine Grossenbegrenzung fur aufsummierte Zugangsberechtigungen von 1 MB pro Unit durchgesetzt. Der Diensteverwalter selbst kann Systemzugangsberechtigungen erhalten, die an Dienste vom einem beherbergenden Container-Verwalter oder VM-Hypervisor weitergeleitet werden konnen. Siehe die Dokumentation zu der Container-Schnittstelle[15] zu Dokumentation zu Ersterem. Fur Zweiteres, ubergeben Sie DMI/SMBIOS[16] OEM-Zeichenketten-Tabelleneintrage (Feldtyp 11) mit einem Prafix >>io.systemd.credential:<< oder >>io.systemd.credential.binary:<<. In beiden Fallen wird ein durch >>=<< getrenntes Schlussel-Wert-Paar erwartet, in letzterem Fall ist die rechte Seite mit Base64 kodiert, wenn sie ausgewertet wird (womit die Hereingabe von binaren Daten ermoglicht wird). Der Schalter fur qemu[17] lautet beispielsweise >>-smbios type=11,value=io.systemd.credential:xx=yy<< oder >>-smbios type=11,value=io.systemd.credential.binary:rick=TmV2ZXIgR29ubmEgR2l2ZSBZb3UgVXA=<<. Alternativ verwenden Sie den >>fw_cfg<<-Knoten >>opt/io.systemd.credentials/<< von qemu(1). Beispielhafter Schalter fur Qemu: >>-fw_cfg name=opt/io.systemd.credentials/mycred,string=supersecret<<. Sie konnen auch von der UEFI-Firmware-Umgebung mittels systemd-stub(7), von der Initrd (siehe systemd(1)) oder auf der Kernelbefehlszeile mittels der Schalters >>systemd.set_credential=<< und >>systemd.set_credential_binary=<< (siehe systemd(1) - dies wird nicht empfohlen, da nicht privilegierter Benutzerraum die Kernelbefehlszeile lesen kann) festgelegt werden. Wird auf ein AF_UNIX-Datenstrom-Socket fur die Verbindung referenziert, dann wird der Ursprung der Verbindung in einem abstrakten Namensraum-Socket liegen, der Informationen uber die Unit und die Zugangsberechtigungskennung in seinem Socket-Namen enthalt. Verwenden Sie getpeername(2), um diese Information abzufragen. Der zuruckgelieferte Socket-Name ist als NUL ZUFALL >>unit<< UNIT >>/<< KENNUNG formatiert, d.h. ein Nullbyte (NUL) (wie fur Socket-Namen aus abstrakten Namensraumen benotigt), gefolgt von einer zufalligen Zeichenkette (die aus alphadezimalen Zeichen besteht), gefolgt von der Zeichenkette >>unit<<, gefolgt von dem anfragenden Unit-Namen, gefolgt von dem Zeichen >>/<<, gefolgt von der erbetenen textuellen Zugangsberechtigungskennung. Beispiel: >>\0adf9d86b6eda275e/unit/foobar.service/credx<<, wobei die Zugangsberechtigung >>credx<< fur eine Unit >>foobar.service<< erbeten wird. Diese Funktionalitat ist nutzlich, wenn ein einzelnes, auf Anfragen wartendes Socket Zugangsberechtigungen fur mehrere Abnehmer bereitstellen soll. Siehe System- und Dienste-Zugangsberechtigungen[18] fur weitere Informationen. Hinzugefugt in Version 247. ImportCredential=GLOB Ubergibt eine oder mehrere Zugangsbereichtigungen an die Unit. Akzeptiert einen Zugangsberechtigungsnamen fur den versucht wird, ein Zugangsberechtigungsdatum zu finden, das der Diensteverwalter selbst unter dem festgelegten Namen empfangen hat - was zur Weiterleitung von Zugangsberechtigungsdaten von einer aufrufenden Umgebung (z.B. einem Container-Verwalter, der den Diensteverwalter aufgerufen hat) an einen Dienst verwandt werden kann. Falls der Zugangsberechtigungsname ein Glob ist, werden alle Zugangsberechtigungen, die auf diesen Glob passen, an die Unit ubergeben. Es wird in den System-Zugangsberechtigungen, den verschlusselten System-Zugangsberchtigungen und unter /etc/credstore/, /run/credstore/, /usr/lib/credstore/, /run/credstore.encrypted/, /etc/credstore.encrypted/ und /usr/lib/credstore.encrypted/ in dieser Reihenfolge nach passenden Zugangsberechtigungen gesucht. Wenn mehrere Zugangsberechtigungen mit dem gleichen Namen gefunden werden, wird die erste gefundene verwandt. Der Globbing-Ausdruck implementiert eine einschrankende Teilmenge von glob(7): nur ein einzelner, abschliessender >>*<<-Platzhalter darf festgelegt werden. Sowohl >>?<<- als auch >>[]<<-Platzhalter sind nicht erlaubt, genau wie >>*<<-Platzhalter, die niergendwo anders ausser am Ende des Glob-Ausdrucks erlaubt sind. Wenn mehrere Zugangsberechtigungen mit gleichem Namen gefunden werden, haben durch LoadCredential= und LoadCredentialEncrypted= gefundene Zugangsberechtigungen Prioritat gegenuber durch ImportCredential= gefundene Zugangsberechtigungen. Hinzugefugt in Version 254. SetCredential=KENNUNG:WERT, SetCredentialEncrypted=KENNUNG:WERT Die Einstellung SetCredential= ist ahnlich zu LoadCredential=, akzeptiert aber einen buchstablichen Wert, der als Daten fur die Zugangsberechtigungen verwandt werden soll, statt eines Dateisystempfades, aus dem die Daten gelesen werden sollen. Verwenden Sie diese Option nicht fur Daten, die geheim gehalten werden sollen, da nicht privilegierte Benutzer darauf mittels IPC zugreifen konnen. Es ist nur sicher, dies fur Benutzerkennungen, offentliches Schlusselmaterial und ahnliche, nicht sensiblen Daten zu verwenden. Verwenden Sie fur alles andere LoadCredential=. Um binare Daten in die Zugangsberechtigungsdaten einzubetten, verwenden Sie C-artige Maskierungen (d.h. >>\n<<, um einen Zeilenumbruch einzubetten oder >>\x00<<, um ein Nullbyte (NUL) einzubetten). Die Einstellung SetCredentialEncrypted= ist identisch zu SetCredential=, erwartet aber eine verschlusselte Zugangsberechtigung in wortlicher Form als Wert. Dies ermoglicht das sichere Einbetten von vertraulichen Zugangsberechtigungen direkt in Unit-Dateien. Verwenden Sie den Schalter -p von systemd-creds(1), um geeignete SetCredentialEncrypted=-Zeilen direkt aus den Klartext-Zugangsberechtigungen zu erstellen. Fur weitere Details siehe LoadCredentialEncrypted= weiter oben. Werden mehrere Zugangsberechtigungen mit dem gleichen Namen gefunden, haben mittels LoadCredential=, LoadCredentialEncrypted= und ImportCredential= gefundene Zugangsberechtigungen Prioritat gegenuber mittels SetCredential= gefundene Zugangsberechtigungen. Somit agiert SetCredential= als Vorgabe, falls mittels der anderen keine Zugangsberchtigungen gefunden werden. In diesem Fall wird der Fehlschlag, die in LoadCredential= oder LoadCredentialEncrypted= festgelegte Zugangsberechtigung nicht abfragen zu konnen, nicht als fatal betrachtet. Hinzugefugt in Version 247. SYSTEM V-KOMPATIBILITAT UtmpIdentifier= Akzeptiert eine Kennzeichnungszeichenkette aus vier Zeichen fur einen utmp(5)- und Wtmp-Eintrag fur diesen Dienst. Dies sollte nur fur Dienste wie getty-Implementierungen (wie agetty(8)) gesetzt werden, bei denen Utmp/Wtmp-Eintrage erstellt und vor und nach der Ausfuhrung bereinigt werden mussen oder fur Dienste, die so ausgefuhrt werden sollen, als ob sie durch einen getty-Prozess ausgefuhrt wurden (siehe unten). Falls die Konfigurationszeichenkette langer als vier Zeichen ist, wird sie gekurzt und die vier Zeichen am Ende werden verwandt. Diese Einstellung interpretiert %I-artige Zeichenkettenersetzungen. Diese Einstellung ist standardmassig nicht gesetzt, d.h. dass fur diesen Dienst keine Utmp-/Wtmp-Eintrage erstellt oder bereinigt werden. UtmpMode= Akzeptiert entweder >>init<<, >>login<< oder >>user<<. Falls UtmpIdentifier= gesetzt ist, steuert dies die Art der fur diesen Dienst erstellten utmp(5)/wtmp-Eintrage. Diese Einstellung ist wirkungslos, ausser UtmpIdentifier= ist auch gesetzt. Falls >>init<< gesetzt ist, wird nur ein INIT_PROCESS-Eintrag erstellt und der aufgerufene Prozess muss eine getty-kompatible Utmp/Wtmp-Logik implementieren. Falls >>login<< gesetzt ist, wird zuerst ein INIT_PROCESS-Eintrag, gefolgt von einem LOGIN_PROCESS-Eintrag erstellt. In diesem Fall muss der aufgerufene Prozess eine login(1)-kompatible Utmp/Wtmp-Logik implementieren. Falls >>user<< festgelegt ist, wird zuerst ein INIT_PROCESS-Eintrag, dann ein LOGIN_PROCESS-Eintrag und schliesslich ein USER_PROCESS-Eintrag erstellt. In diesem Fall kann der Prozess jeder Prozess sein, der zum Betrieb als Sitzungsleiter geeignet ist. Standardmassig >>init<<. Hinzugefugt in Version 225. UMGEBUNGSVARIABLEN IN ERZEUGTEN PROZESSEN Durch den Diensteverwalter gestartete Prozesse werden mit einem Umgebungsvariablenblock gestartet, der aus verschiedenen Quellen zusammengesetzt ist. Prozesse, die durch den Systemdiensteverwalter gestartet werden, erben im Allgemeinen die fur den Diensteverwalter selbst gesetzten Umgebungsvariablen nicht (dies kann durch PassEnvironment= geandert werden), aber Prozesse, die durch Benutzerdiensteverwalterinstanzen gestartet werden, erben im Allgemein alle fur den Diensteverwalter selbst gesetzten Umgebungsvariablen. Fur jeden aufgerufenen Prozess wird die Liste der gesetzten Umgebungsvariablen aus den folgenden Quellen zusammengestellt: o Variablen, die global fur den Diensteverwalter mittels der Einstellung DefaultEnvironment= in systemd-system.conf(5), der Kernelbefehlszeilenoption systemd.setenv= von systemd(1) verstanden werden oder mittels des Unterbefehls set-environment von systemctl gesetzt werden. o Durch den Diensteverwalter selbst definierte Variablen (siehe nachfolgende Liste). o Variablen, die durch den Umgebungsvariablenblock des Diensteverwalters selbst gesetzt sind (abhangig von PassEnvironment= fur den Systemdiensteverwalter). o Mittels Environment= in der Unit-Datei gesetzte Variablen. o Aus mit EnvironmentFile= in der Unit-Datei festgelegten Dateien gelesene Variablen. o Falls PAMName= wirksam ist, siehe pam_env(8), durch alle PAM-Module gesetzte Variablen. Falls die gleiche Umgebungsvariable aus mehreren dieser Quellen gesetzt wird, gewinnt die letzte Quelle, wobei die Reihenfolge der obigen Liste zahlt. Beachten Sie, dass als abschliessender Schritt alle in UnsetEnvironment= aufgefuhrten Variablen aus der zusammengestellten Variablenliste entfernt werden, direkt bevor sie an den ausgefuhrten Prozess ubergeben wird. Die allgemeine Philosphie ist, Prozessen eine kleine, gepflegte Liste von Umgebungsvariablen offenzulegen. Vom Diensteverwalter (PID 1) gestartete Dienste werden ohne zusatzliche Dienste-spezifische Konfiguration und mit nur ein paar Umgebungsvariablen gestartet. Der Benutzerverwalter erbt Umgebungsvariablen wie jeder andere Systemdienst, kann aber ein paar zusatzliche Umgebungsvariablen von PAM und typischerweise zusatzliche importierte Variablen, wenn der Benutzer eine graphische Sitzung startet, empfangen. Es wird empfohlen, die Umgebungsblocke sowohl im System- als auch in Benutzerverwaltern schlank zu halten. Vom Import aller durch graphische Sitzungen oder einer der Benutzer-Shells ererbten Variablen wird nachdrucklich abgeraten. Tipp: systemd-run -P env und systemd-run --user -P env geben die wirksamen System- und Benutzerdiensteverwalter-Umgebungsblocke aus. Vom Diensteverwalter gesetzte oder ausgebreitete Umgebungsvariablen Die folgenden Umgebungsvariablen werden fur jeden durch den Diensteverwalter aufgerufenen Prozess ausgebreitet oder intern erstellt: $PATH Doppelpunkt-getrennte Liste von Verzeichnissen, die beim Starten von Programmen verwandt werden. systemd verwendet einen festgelegten Wert von >>/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin<< im Systemverwalter. Im Falle des Benutzerverwalters kann durch die Distribution ein anderer Pfad konfiguriert sein. Es wird empfohlen, sich auf die Reihenfolge der Eintrage nicht zu verlassen, und nur ein Programm mit einem vorgegebenen Namen in $PATH zu haben. Hinzugefugt in Version 208. $LANG Locale. Kann in locale.conf(5) oder auf der Kernelbefehlszeile gesetzt werden (siehe systemd(1) und kernel-command-line(7)). Hinzugefugt in Version 208. $USER, $LOGNAME, $HOME, $SHELL Benutzername (zweimal), Home-Verzeichnis und die Anmelde-Shell. $USER wird bedingungslos gesetzt, wahrend $HOME, $LOGNAME und $SHELL nur fur die Units gesetzt werden, die User= gesetzt und SetLoginEnvironment= nicht oder auf wahr gesetzt haben. Fur Benutzerdienste werden diese Variablen typischerweise aus dem Verwalter selbst geerbt. Siehe passwd(5). Hinzugefugt in Version 208. $INVOCATION_ID Enthalt eine zufallige, 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 andert, 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 ausgefuhrten Prozesse ubergeben. Hinzugefugt in Version 232. $XDG_RUNTIME_DIR Das Verzeichnis, das fur Laufzeitobjekte (wie IPC-Objekte) und fluchtige Zustande verwandt werden soll. Wird fur alle von der Benutzer-systemd-Instanz ausgefuhrten Prozesse sowie von allen Systemdiensten, die PAMName= mit einem PAM-Stack, der pam_systemd enthalt, verwandt wird, gesetzt. Siehe unten und pam_systemd(8) fur weitere Informationen. Hinzugefugt in Version 208. $RUNTIME_DIRECTORY, $STATE_DIRECTORY, $CACHE_DIRECTORY, $LOGS_DIRECTORY, $CONFIGURATION_DIRECTORY Absolute Pfade zu den in RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory= und ConfigurationDirectory= definierten Verzeichnissen, wenn diese Einstellungen verwandt werden. Hinzugefugt in Version 244. $CREDENTIALS_DIRECTORY Ein absoluter Pfad zu einem Unit-spezifischen Verzeichnis mit Zugangsberechtigungen, die mittels ImportCredential=/LoadCredential=/SetCredential= konfiguriert wurden. Das Verzeichnis ist als rein lesbar markiert und auf nicht auslagerbaren Speicher abgelegt (falls unterstutzt und erlaubt) und kann nur von der UID aus zugegriffen werden, die der Unit via User= oder DynamicUser= zugeordnet ist (und dem Systemverwalter). Hinzugefugt in Version 247. $MAINPID Die PID des Hauptprozesses der Unit, falls bekannt. Dies wird nur fur durch ExecReload= und Ahnliches aufgerufene Steuerprozesse gesetzt. Hinzugefugt in Version 209. $MANAGERPID Die PID der Benutzer-systemd-Instanz, gesetzt fur davon erzeugte Prozesse. Hinzugefugt in Version 208. $LISTEN_FDS, $LISTEN_PID, $LISTEN_FDNAMES Informationen uber Dateideskriptoren, die an einen Dienst fur Socket-Aktivierung weitergegeben wurden. Siehe sd_listen_fds(3). Hinzugefugt in Version 208. $NOTIFY_SOCKET Das Socket, mit dem sd_notify() kommuniziert. Siehe sd_notify(3). Hinzugefugt in Version 229. $WATCHDOG_PID, $WATCHDOG_USEC Informationen uber Watchdog-Aufrechterhaltungsbenachrichtigungen. Siehe sd_watchdog_enabled(3). Hinzugefugt in Version 229. $SYSTEMD_EXEC_PID Die PID des Unit-Prozesses (z.B. des durch ExecStart= aufgerufenen Prozesses). Der Kind-Prozess kann diese Informationen dazu verwenden, um zu ermitteln, ob der Prozess direkt vom Diensteverwalter oder indirekt als Kind eines anderen Prozesses erzeugt wurde, indem er diesen Wert mit der aktuellen PID vergleicht (ahnlich des von sd_listen_fds(3) mit $LISTEN_PID und $LISTEN_FDS verwandten Schemas). Hinzugefugt in Version 248. $TERM Terminaltyp, nur fur mit einem Terminal verbundene Units gesetzt (StandardInput=tty, StandardOutput=tty oder StandardError=tty). Siehe termcap(5). Hinzugefugt in Version 209. $LOG_NAMESPACE Enthalt den Namen des ausgewahlten Protokollierungsnamensraums, wenn die Einstellung LogNamespace= verwandt wird. Hinzugefugt in Version 246. $JOURNAL_STREAM Falls die Standardausgabe oder Standardfehlerausgabe des ausgefuhrten Prozesses mit dem Journal verbunden ist (beispielsweise durch Setzen von StandardError=journal), enthalt $JOURNAL_STREAM das Gerat und die Inode-Nummer des verbindenden Dateideskriptors, dezimal formatiert, getrennt durch einen Doppelpunkt (>>:<<). Dies erlaubt es aufgerufenen Prozessen, sicher zu uberprufen, ob ihre Standardausgabe oder Standardfehlerausgabe mit dem Journal verbunden sind. Das Gerat und die Inode-Nummer des Dateideskriptors sollte mit den in der Umgebungsvariable gesetzten Werten verglichen werden, um zu bestimmen, ob die Prozessausgabe immer noch mit dem Journal verbunden ist. Beachten Sie, dass es im Allgemeinen nicht ausreicht, zu prufen, ob $JOURNAL_STREAM uberhaupt gesetzt ist, da Dienste externe Prozesse aufrufen konnten, die ihre Standardausgabe oder Fehlerausgabe ersetzen konnten, ohne dabei die Umgebungsvariable zuruckzusetzen. Falls sowohl die Standardausgabe als auch der Standardfehler des ausgefuhrten Prozesses mit dem Journal uber ein Datenstrom-Socket verbunden sind, wird diese Umgebungsvariable Informationen uber den Standardfehlerdatenstrom enthalten, da dies normalerweise das bevorzugte Ziel fur Protokolldaten ist. (Beachten Sie, dass typischerweise der gleiche Datenstrom sowohl fur die Standardausgabe als auch den Standardfehler verwandt wird und daher die Umgebungsvariable sehr wahrscheinlich Gerate- und Inode-Informationen enthalten wird, die auf beide Datenstromdateideskriptoren passt.) Diese Umgebungsvariable ist hauptsachlich nutzlich, um Diensten zu erlauben, ihr verwandtes Protokollierungsprotokoll optional (mittels sd_journal_print(3) und anderer Funktionen) auf das native Journal-Protokoll anzuheben, falls ihre Standardausgabe oder Standardfehlerausgabe sowieso mit dem Journal verbunden ist. Damit wird die Lieferung von strukturierten Metadaten zusammen mit den protokollierten Nachrichten ermoglicht. Hinzugefugt in Version 231. $SERVICE_RESULT Diese Variable, die nur fur den Dienste-Unit-Typ verwandt wird, wird an alle ExecStop=- und ExecStopPost=-Prozesse weitergegeben und kodiert das >>Ergebnis<< des Prozesses. Derzeit sind die folgenden Werte definiert: Tabelle 5. Definierte $SERVICE_RESULT-Werte +------------------+----------------------------+ |Wert | Bedeutung | +------------------+----------------------------+ |"Erfolg" | Der Dienst lief | | | erfolgreich und beendete | | | sich ordnungsgemass. | +------------------+----------------------------+ |"protocol" | Das Protokoll wurde | | | verletzt: der Dienst hat | | | nicht die von seiner | | | Unit-Konfiguration | | | verlangten Schritte | | | absolviert (insbesondere | | | was in der Einstellung | | | Type= konfiguriert wurde). | +------------------+----------------------------+ |"timeout" | Einer der Schritte hat die | | | Zeit uberschritten. | +------------------+----------------------------+ |"exit-code" | Diensteprozess hat sich | | | mit einen von Null | | | verschiedenen Exit-Code | | | beendet; siehe $EXIT_CODE | | | unten fur den tatsachlich | | | zuruckgelieferten | | | Exit-Code. | +------------------+----------------------------+ |"signal" | Ein Diensteprozess wurde | | | durch ein Signal | | | regelwidrig beendet; ohne | | | einen Speicherauszug. | | | Siehe $EXIT_CODE unten fur | | | das tatsachliche Signal, | | | das die Beendigung | | | ausloste. | +------------------+----------------------------+ |"core-dump" | Ein Diensteprozess wurde | | | durch ein Signal | | | regelwidrig beendet und | | | hat einen Speicherauszug | | | ausgegeben. Siehe | | | $EXIT_CODE unten fur das | | | Signal, das die Beendigung | | | ausloste. | +------------------+----------------------------+ |"watchdog" | Der Totmannschalter des | | | Watchdogs war fur diesen | | | Dienst aktiviert, aber die | | | Frist wurde verpasst. | +------------------+----------------------------+ |"exec-condition" | Der Dienst wurde nicht | | | ausgefuhrt, da | | | ExecCondition= fehlschlug. | +------------------+----------------------------+ |"oom-kill" | Ein Diensteprozess wurde | | | durch den | | | Speicherknappheit- | | | (OOM-)Killer beendet. | +------------------+----------------------------+ |"start-limit-hit" | Fur die Unit war eine | | | Startbegrenzung definiert | | | und wurde erreicht, | | | wodurch der Start der Unit | | | fehlschlug. Siehe | | | StartLimitIntervalSec= und | | | StartLimitBurst= von | | | systemd.unit(5) fur | | | Details. | +------------------+----------------------------+ |"resources" | Eine Auffangbedingung, | | | falls eine Systemaktion | | | fehlschlug. | +------------------+----------------------------+ Diese Umgebungsvariable ist nutzlich, um den Fehlschlag oder die erfolgreiche Beendigung eines Dienstes zu uberwachen. Obwohl diese Variable sowohl in ExecStop= als auch ExecStopPost= verfugbar ist, ist es normalerweise eine bessere Wahl, die Uberwachungswerkzeuge in Letzterer zu platzieren, da Erstere nur fur Dienste aufgerufen wird, die ihren Start korrekt verwaltet haben und Letztere sowohl Dienste abdeckt, die wahrend ihres Startens fehlschlugen als auch solche, die wahrend ihrer Laufzeit fehlschlugen. Hinzugefugt in Version 232. $EXIT_CODE, $EXIT_STATUS Diese Umgebungsvariablen, die nur fur den Dienste-Unit-Typ definiert sind, werden an alle Prozesse aus ExecStop= und ExecStopPost= ubergeben und enthalten Exit-Status/Code-Informationen uber den Hauptprozess des Dienstes. Fur die genaue Definition des Exit-Codes und -Status, siehe wait(2). $EXIT_CODE ist entweder >>exited<<, >>killed<< oder >>dumped<<. $EXIT_STATUS enthalt den als Zeichenkette formatierten numerischen Exit-Code, falls $EXIT_CODE >>exited<< enthalt und andernfalls den Signalnamen. Beachten Sie, dass diese Umgebungsvariablen nur gesetzt sind, falls es dem Diensteverwalter gelang, den Hauptprozess des Dienstes zu starten und zu identifizieren. Tabelle 6. Zusammenfassung der moglichen Variablenwerte fur Diensteergebnisse +------------------+------------------+---------------------+ |$SERVICE_RESULT | $EXIT_CODE | $EXIT_STATUS | +------------------+------------------+---------------------+ |"Erfolg" | "killed" | >>HUP<<, >>INT<<, | | | | >>TERM<<, >>PIPE<< | | +------------------+---------------------+ | | "exited" | "0" | +------------------+------------------+---------------------+ |"protocol" | not set | not set | | +------------------+---------------------+ | | "exited" | "0" | +------------------+------------------+---------------------+ |"timeout" | "killed" | >>TERM<<, >>KILL<< | | +------------------+---------------------+ | | "exited" | >>0<<, >>1<<, | | | | >>2<<, >>3<<, | | | | >>255<< | +------------------+------------------+---------------------+ |"exit-code" | "exited" | >>1<<, >>2<<, | | | | >>3<<, , >>255<< | +------------------+------------------+---------------------+ |"signal" | "killed" | >>HUP<<, >>INT<<, | | | | >>KILL<<, | +------------------+------------------+---------------------+ |"core-dump" | "dumped" | >>ABRT<<, >>SEGV<<, | | | | >>QUIT<<, | +------------------+------------------+---------------------+ |"watchdog" | "dumped" | "ABRT" | | +------------------+---------------------+ | | "killed" | >>TERM<<, >>KILL<< | | +------------------+---------------------+ | | "exited" | >>0<<, >>1<<, | | | | >>2<<, >>3<<, | | | | >>255<< | +------------------+------------------+---------------------+ |"exec-condition" | "exited" | >>1<<, >>2<<, | | | | >>3<<, >>4<<, , | | | | >>254<< | +------------------+------------------+---------------------+ |"oom-kill" | "killed" | >>TERM<<, >>KILL<< | +------------------+------------------+---------------------+ |"start-limit-hit" | not set | not set | +------------------+------------------+---------------------+ |"resources" | jeder der obigen | jeder der obigen | +------------------+------------------+---------------------+ |Beachten Sie: der Prozess kann auch durch ein Signal | |beendet werden, das nicht von Systemd gesandt wurde. | |Insbesondere kann der Prozess sich selbst in einem Handler | |ein beliebiges Signal fur jedes der nicht maskierbaren | |Signale senden. Nichtsdestotrotz wurden in den Spalten | |>>timeout<< und >>watchdog<< nur die Signale aufgenommen, | |die Systemd sendet. Desweiteren konnen mittels | |SuccessExitStatus= zusatzliche Exit-Status erklart werden, | |um die ordnungsgemasse Beendigung anzuzeigen, was in der | |Tabelle nicht wiedergegeben wird. | +-----------------------------------------------------------+ Hinzugefugt in Version 232. $MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE, $MONITOR_EXIT_STATUS, $MONITOR_INVOCATION_ID, $MONITOR_UNIT Diese Umgebungsvariablen, die nur fur den Dienste-Unit-Typ definiert sind, werden an alle ExecStart=- und ExecStartPre=-Prozesse weitergegeben, die in von OnFailure=- oder OnSuccess=-Abhangigkeiten ausgelosten Diensten ausgefuhrt werden. Die Variablen $MONITOR_SERVICE_RESULT, $MONITOR_EXIT_CODE und $MONITOR_EXIT_STATUS akzeptieren die gleichen Werte wie fur die Prozesse ExecStop= und ExecStopPost=. Die Variablen $MONITOR_INVOCATION_ID und $MONITOR_UNIT werden auf die Aufrufkennung und den Unit-Namen des Dienstes, der die Abhangigkeit ausloste, gesetzt. Beachten Sie, dass diese Variablen nicht weitergegeben werden, wenn mehrere Dienste die gleiche Unit auslosten. In diesem Fall sollten Sie stattdessen eine Vorlage-Handhabungs-Unit verwenden: >>OnFailure=handler@%n.service<< fur Units, die keine Vorlagen sind oder >>OnFailure=handler@%p-%i.service<< fur Units, die Vorlagen sind. Hinzugefugt in Version 251. $PIDFILE Der Pfad zu der konfigurierten PID-Datei, falls der Prozess im Auftrag des Dienstes, der die Einstellung PIDFile= verwendet, einen Fork durchgefuhrt hat, siehe systemd.service(5) fur Details. Dienste-Code kann diese Umgebungsvariable verwenden, um automatisch eine PID-Datei am durch die Unit-Datei konfigurierten Ort zu erstellen. Dieses Feld ist auf einen absoluten Pfad in dem Dateisystem gesetzt. Hinzugefugt in Version 242. $REMOTE_ADDR, $REMOTE_PORT Falls dies eine Unit ist, die mittels verbindungsbezogener Socket-Aktivierung gestartet wurde (d.h. mittels einer Socket-Unit mit Accept=yes), dann enthalten diese Umgebungsvariablen die IP-Adresse und die Port-Nummer der fernen Gegenstelle der Socket-Verbindung. Hinzugefugt in Version 254. $TRIGGER_UNIT, $TRIGGER_PATH, $TRIGGER_TIMER_REALTIME_USEC, $TRIGGER_TIMER_MONOTONIC_USEC Falls die Unit dynamisch aktiviert wurde (z.B. durch eine entsprechende Pfad- oder Timer-Unit), dann werden die Unit, die sie ausloste und andere Typ-abhangige Informationen uber diese Variablen hereingegeben. Beachten Sie, dass diese Informationen so gut wie moglich bereitgestellt werden. Zum Beispiel werden mehrere Trigger, die nacheinander passieren, verbunden und nur einer wird berichtet und ohne Garantie, welcher davon. Daher ist diese Variable in den meisten Fallen eher informativ, d.h. nutzlich zur Fehlersuche, verlustbehaftet und sollte nicht als Grundlage verwandt werden, um einen umfassenden Grund fur die Aktivierung weiterzugeben. Hinzugefugt in Version 252. $MEMORY_PRESSURE_WATCH, $MEMORY_PRESSURE_WRITE Falls Speicherdruckuberwachung fur diese Dienste-Unit aktiviert ist, ist dies der zu beobachtende Pfad und die Daten, die darein geschrieben werden sollen. Siehe Umgang mit Speicherdruck[19] zu Details uber diese Variablen und die Diensteprotokolldaten, die diese transportieren. Hinzugefugt in Version 254. $FDSTORE Die maximale Anzahl an Dateideskriptoren, die in dem Verwalter fur diesen Dienst gespeichert werden kann. Diese Variable ist gesetzt, wenn der Dateideskriptorspeicher fur den Dienst aktiviert ist, d.h. FileDescriptorStoreMax= auf einen von Null verschiedenen Wert gesetzt ist (siehe systemd.service(5) zu Details). Anwendungen konnen diese Umgebungsvariable prufen, bevor sie Dateideskriptoren mittels sd_pid_notify_with_fds(3) an den Diensteverwalter senden. Hinzugefugt in Version 254. Fur Systemdienste konnen zusatzliche, durch Systemd definierte Umgebungsvariablen fur Dienste gesetzt werden, wenn PAMName= aktiviert und pam_systemd Teil des ausgewahlten PAM-Stacks ist. Dies sind insbesondere $XDG_SEAT und $XDG_VTNR, siehe pam_systemd(8) fur Details. PROZESS-EXIT-CODES Beim Aufruf eines Unit-Prozesses konnte der Diensteverwalter moglicherweise nicht in der Lage sein, die mit den oben dargestellten Einstellungen konfigurierten Ausfuhrungsparameter zu setzen. In diesem Fall wird sich der bereits erstellte Diensteprozess mit einem von Null verschiedenen Exit-Code beenden, bevor die konfigurierte Befehlszeile ausgefuhrt wird. (Oder, mit anderen Worten, der Kindprozess hat sich mit diesen Fehler-Codes beendet, nachdem er mit dem Systemaufruf fork(2) erstellt wurde, aber bevor der zugehorige Systemaufruf execve(2) erfolgte.) Insbesondere werden die durch die C-Bibliothek, die LSB-Spezifikation und durch den Systemd-Diensteverwalter selbst definierten Exit-Codes verwandt. Die folgenden grundlegenden Dienste-Exit-Codes sind durch die C-Bibliothek definiert. Tabelle 7. Grundlegende Exit-Codes der C-Bibliothek +----------+-------------------+------------------+ |Exit-Code | Symbolischer Name | Beschreibung | +----------+-------------------+------------------+ |0 | EXIT_SUCCESS | Generischer | | | | Erfolgs-Code. | +----------+-------------------+------------------+ |1 | EXIT_FAILURE | Generischer | | | | Fehlschlag oder | | | | unspezifizierter | | | | Fehler. | +----------+-------------------+------------------+ Die folgenden Dienste-Exit-Codes sind durch die LSB-Spezifikation[20] festgelegt. Tabelle 8. LSB-Dienste-Exit-Codes +----------+----------------------+---------------------+ |Exit-Code | Symbolischer Name | Beschreibung | +----------+----------------------+---------------------+ |2 | EXIT_INVALIDARGUMENT | Ungultige oder | | | | uberzahlige | | | | Argumente. | +----------+----------------------+---------------------+ |3 | EXIT_NOTIMPLEMENTED | Nicht | | | | implementierte | | | | Funktionalitat. | +----------+----------------------+---------------------+ |4 | EXIT_NOPERMISSION | Der Benutzer hat | | | | nicht genug | | | | Privilegien. | +----------+----------------------+---------------------+ |5 | EXIT_NOTINSTALLED | Das Programm ist | | | | nicht installiert. | +----------+----------------------+---------------------+ |6 | EXIT_NOTCONFIGURED | Das Programm ist | | | | nicht konfiguriert. | +----------+----------------------+---------------------+ |7 | EXIT_NOTRUNNING | Das Programm lauft | | | | nicht. | +----------+----------------------+---------------------+ Die LSB-Spezifikation schlagt vor, dass Fehler-Code 200 und hoher fur Implementierungen reserviert ist. Einige von ihnen werden vom Diensteverwalter benutzt, um Probleme beim Aufrufen von Prozessen anzuzeigen. Tabelle 9. Systemd-spezifische Exit-Codes +----------+------------------------------+---------------------------------------------+ |Exit-Code | Symbolischer Name | Beschreibung | +----------+------------------------------+---------------------------------------------+ |200 | EXIT_CHDIR | Anderung des angeforderten | | | | Arbeitsverzeichnisses schlug fehl. Siehe | | | | WorkingDirectory= oben. | +----------+------------------------------+---------------------------------------------+ |201 | EXIT_NICE | Scheduling-Prioritat (Nice-Stufe) konnte | | | | nicht gesetzt werden. Siehe Nice= oben. | +----------+------------------------------+---------------------------------------------+ |202 | EXIT_FDS | Ungewunschter Dateideskriptor konnte nicht | | | | geschlossen werden oder ubergebene | | | | Dateideskriptoren konnten nicht angepasst | | | | werden. | +----------+------------------------------+---------------------------------------------+ |203 | EXIT_EXEC | Die tatsachliche Ausfuhrung des Prozesses | | | | schlug fehl (genauer, der Systemaufruf | | | | execve(2)). Hochstwahrscheinlich wird dies | | | | durch ein fehlendes oder nicht zugreifbares | | | | Programm hervorgerufen. | +----------+------------------------------+---------------------------------------------+ |204 | EXIT_MEMORY | Aufgrund von Speicherknappheit konnte eine | | | | Aktion nicht durchgefuhrt werden. | +----------+------------------------------+---------------------------------------------+ |205 | EXIT_LIMITS | Ressourcenbegrenzungen konnten nicht | | | | angepasst werden. Siehe LimitCPU= und | | | | verwandte Einstellungen oben. | +----------+------------------------------+---------------------------------------------+ |206 | EXIT_OOM_ADJUST | OOM-Einstellungen konnten nicht angepasst | | | | werden. Siehe OOMScoreAdjust= oben. | +----------+------------------------------+---------------------------------------------+ |207 | EXIT_SIGNAL_MASK | Prozesssignalmaske konnte nicht gesetzt | | | | werden. | +----------+------------------------------+---------------------------------------------+ |208 | EXIT_STDIN | Standardeingabe konnte nicht gesetzt | | | | werden. Siehe StandardInput= oben. | +----------+------------------------------+---------------------------------------------+ |209 | EXIT_STDOUT | Standardausgabe konnte nicht gesetzt | | | | werden. Siehe StandardOutput= oben. | +----------+------------------------------+---------------------------------------------+ |210 | EXIT_CHROOT | Wurzelverzeichnis konnte nicht geandert | | | | werden (chroot(2)). Siehe | | | | RootDirectory=/RootImage= oben. | +----------+------------------------------+---------------------------------------------+ |211 | EXIT_IOPRIO | E/A-Scheduling-Prioritat konnte nicht | | | | gesetzt werden. Siehe | | | | IOSchedulingClass=/IOSchedulingPriority= | | | | oben. | +----------+------------------------------+---------------------------------------------+ |212 | EXIT_TIMERSLACK | Der Timer-Spielraum konnte nicht | | | | eingerichtet werden. Siehe TimerSlackNSec= | | | | oben. | +----------+------------------------------+---------------------------------------------+ |213 | EXIT_SECUREBITS | Prozess-Sicherheits-Bits konnten nicht | | | | gesetzt werden. Siehe SecureBits= oben. | +----------+------------------------------+---------------------------------------------+ |214 | EXIT_SETSCHEDULER | CPU-Scheduling konnte nicht eingerichtet | | | | werden. Siehe | | | | CPUSchedulingPolicy=/CPUSchedulingPriority= | | | | oben. | +----------+------------------------------+---------------------------------------------+ |215 | EXIT_CPUAFFINITY | CPU-Affinitat konnte nicht eingerichtet | | | | werden. Siehe CPUAffinity= oben. | +----------+------------------------------+---------------------------------------------+ |216 | EXIT_GROUP | Gruppen-Zugangsberechtigungen konnten nicht | | | | bestimmt oder geandert werden. Siehe | | | | Group=/SupplementaryGroups= oben. | +----------+------------------------------+---------------------------------------------+ |217 | EXIT_USER | Benutzer-Zugangsberechtigungen konnten | | | | nicht bestimmt oder geandert werden oder | | | | Benutzernamensraume eingerichtet werden. | | | | Siehe User=/PrivateUsers= oben. | +----------+------------------------------+---------------------------------------------+ |218 | EXIT_CAPABILITIES | Capabilities konnten nicht abgegeben oder | | | | Umgebungs-Capabilities angewandt werden. | | | | Siehe | | | | CapabilityBoundingSet=/AmbientCapabilities= | | | | oben. | +----------+------------------------------+---------------------------------------------+ |219 | EXIT_CGROUP | Einrichten der Dienste-Control-Gruppe | | | | schlug fehl. | +----------+------------------------------+---------------------------------------------+ |220 | EXIT_SETSID | Erstellung einer neuen Prozesssitzung | | | | schlug fehl. | +----------+------------------------------+---------------------------------------------+ |221 | EXIT_CONFIRM | Ausfuhrung wurde vom Benutzer abgebrochen. | | | | Siehe die Kernelbefehlszeileneinstellung | | | | systemd.confirm_spawn= in | | | | kernel-command-line(7) fur Details. | +----------+------------------------------+---------------------------------------------+ |222 | EXIT_STDERR | Standardfehlerausgabe konnte nicht | | | | eingerichtet werden. Siehe StandardError= | | | | oben. | +----------+------------------------------+---------------------------------------------+ |224 | EXIT_PAM | PAM-Sitzung konnte nicht eingerichtet | | | | werden. Siehe PAMName= oben. | +----------+------------------------------+---------------------------------------------+ |225 | EXIT_NETWORK | Netzwerknamensraume konnten nicht | | | | eingericht werden. Siehe PrivateNetwork= | | | | oben. | +----------+------------------------------+---------------------------------------------+ |226 | EXIT_NAMESPACE | Einhange-, UTS- oder IPC-Namensraume | | | | konnten nicht eingerichtet werden. Siehe | | | | ReadOnlyPaths=, ProtectHostname=, | | | | PrivateIPC= und verwandte Einstellungen | | | | oben. | +----------+------------------------------+---------------------------------------------+ |227 | EXIT_NO_NEW_PRIVILEGES | Neue Privilegien konnten nicht deaktiviert | | | | werden. Siehe NoNewPrivileges=yes oben. | +----------+------------------------------+---------------------------------------------+ |228 | EXIT_SECCOMP | Systemaufruffilter konnten nicht angewandt | | | | werden. Siehe SystemCallFilter= und | | | | verwandte Einstellungen oben. | +----------+------------------------------+---------------------------------------------+ |229 | EXIT_SELINUX_CONTEXT | SELinux-Kontext konnte nicht bestimmt oder | | | | geandert werden Siehe SELinuxContext= oben. | +----------+------------------------------+---------------------------------------------+ |230 | EXIT_PERSONALITY | Ausfuhrungsdomane (Personalitat) konnte | | | | nicht eingerichtet werden. Siehe | | | | Personality= oben. | +----------+------------------------------+---------------------------------------------+ |231 | EXIT_APPARMOR_PROFILE | AppArmor konnte nicht vorbereitet werden. | | | | SIehe AppArmorProfile= oben. | +----------+------------------------------+---------------------------------------------+ |232 | EXIT_ADDRESS_FAMILIES | Adressfamilien konnten nicht beschrankt | | | | werden. Siehe RestrictAddressFamilies= | | | | oben. | +----------+------------------------------+---------------------------------------------+ |233 | EXIT_RUNTIME_DIRECTORY | Laufzeitverzeichnis konnte nicht | | | | eingerichtet werden. Siehe | | | | RuntimeDirectory= und verwandte | | | | Einstellungen oben. | +----------+------------------------------+---------------------------------------------+ |235 | EXIT_CHOWN | Socket-Eigentumerschaft konnte nicht | | | | angepasst werden. Wird nur fur Socket-Units | | | | verwandt. | +----------+------------------------------+---------------------------------------------+ |236 | EXIT_SMACK_PROCESS_LABEL | SMACK-Sicherheits-Label konnte nicht | | | | gesetzt werden. Siehe SmackProcessLabel= | | | | oben. | +----------+------------------------------+---------------------------------------------+ |237 | EXIT_KEYRING | Kernel-Schlusselbund konnte nicht | | | | eingerichtet werden. | +----------+------------------------------+---------------------------------------------+ |238 | EXIT_STATE_DIRECTORY | Zustandsverzeichnis der Unit konnte nicht | | | | eingerichtet werden. Siehe StateDirectory= | | | | oben. | +----------+------------------------------+---------------------------------------------+ |239 | EXIT_CACHE_DIRECTORY | Zwischenspeicherverzeichnis der Unit konnte | | | | nicht eingerichtet werden. Siehe | | | | CacheDirectory= oben. | +----------+------------------------------+---------------------------------------------+ |240 | EXIT_LOGS_DIRECTORY | Protokollierverzeichnis der Unit konnte | | | | nicht eingerichtet werden. Siehe | | | | LogsDirectory= oben. | +----------+------------------------------+---------------------------------------------+ |241 | EXIT_CONFIGURATION_DIRECTORY | Konfigurationsverzeichnis der Unit konnte | | | | nicht eingerichtet werden. Siehe | | | | ConfigurationDirectory= oben. | +----------+------------------------------+---------------------------------------------+ |242 | EXIT_NUMA_POLICY | NUMA-Richtlinie der Unit konnte nicht | | | | eingerichtet werden. Siehe NUMAPolicy= und | | | | NUMAMask= oben. | +----------+------------------------------+---------------------------------------------+ |243 | EXIT_CREDENTIALS | Zugangsberechtigungen der Unit konnten | | | | nicht eingerichtet werden. Siehe | | | | ImportCredential=, LoadCredential= und | | | | SetCredential= oben. | +----------+------------------------------+---------------------------------------------+ |245 | EXIT_BPF | BPF-Beschrankungen konnten nicht angewandt | | | | werden. Siehe RestrictFileSystems= oben. | +----------+------------------------------+---------------------------------------------+ Schliesslich definieren die BSD-Betriebssysteme eine Reihe von Exit-Codes, die typischerweise auch auf Linux-Systemen definiert sind: Tabelle 10. BSD-Exit-Codes +----------+-------------------+-------------------------------+ |Exit-Code | Symbolischer Name | Beschreibung | +----------+-------------------+-------------------------------+ |64 | EX_USAGE | Befehlszeilenbenutzungsfehler | +----------+-------------------+-------------------------------+ |65 | EX_DATAERR | Datenformatfehler | +----------+-------------------+-------------------------------+ |66 | EX_NOINPUT | Eingabe kann nicht geoffnet | | | | werden | +----------+-------------------+-------------------------------+ |67 | EX_NOUSER | Empfangerin unbekannt | +----------+-------------------+-------------------------------+ |68 | EX_NOHOST | Rechnername unbekannt | +----------+-------------------+-------------------------------+ |69 | EX_UNAVAILABLE | Dienst nicht verfugbar | +----------+-------------------+-------------------------------+ |70 | EX_SOFTWARE | interner Softwarefehler | +----------+-------------------+-------------------------------+ |71 | EX_OSERR | Systemfehler (z.B. Fork kann | | | | nicht ausgefuhrt werden) | +----------+-------------------+-------------------------------+ |72 | EX_OSFILE | kritische Betriebssystemdatei | | | | fehlt | +----------+-------------------+-------------------------------+ |73 | EX_CANTCREAT | (Benutzer)-Ausgabedatei kann | | | | nicht erstellt werden | +----------+-------------------+-------------------------------+ |74 | EX_IOERR | Eingabe/Ausgabe-Fehler | +----------+-------------------+-------------------------------+ |75 | EX_TEMPFAIL | Temporarer Fehlschlag, | | | | Benutzer sollte es noch | | | | einmal versuchen | +----------+-------------------+-------------------------------+ |76 | EX_PROTOCOL | Ferner Fehler im Protokoll | +----------+-------------------+-------------------------------+ |77 | EX_NOPERM | Erlaubnis verweigert | +----------+-------------------+-------------------------------+ |78 | EX_CONFIG | Konfigurationsfehler | +----------+-------------------+-------------------------------+ BEISPIELE Beispiel 3. $MONITOR_*-Verwendung Ein Dienst myfailer.service, der eine Abhangigkeit OnFailure= auslosen kann. [Unit] Description=Dienst, der eine Abhangigkeit OnFailure= auslosen kann OnFailure=myhandler.service [Service] ExecStart=/bin/meinprogramm Ein Dienst mysuccess.service, der eine Abhangigkeit OnSuccess== auslosen kann. [Unit] Description=Dienst, der eine Abhangigkeit OnSuccess= auslosen kann OnSuccess=myhandler.service [Service] ExecStart=/bin/meinzweitesprogramm Ein Dienst myhandler.service, der von jedem der obigen Dienste ausgelost werden kann. [Unit] Description=Agiert bei fehlschlagenden oder erfolgreichen Diensten [Service] ExecStart=/bin/bash -c "echo $MONITOR_SERVICE_RESULT $MONITOR_EXIT_CODE $MONITOR_EXIT_STATUS $MONITOR_INVOCATION_ID $MONITOR_UNIT" Falls myfailer.service ausgefuhrt und mit einem Fehlschlag beendet wurde, dann wurde myhandler.service ausgelost und die Uberwachungsvariablen wie folgt gesetzt: MONITOR_SERVICE_RESULT=exit-code MONITOR_EXIT_CODE=exited MONITOR_EXIT_STATUS=1 MONITOR_INVOCATION_ID=cc8fdc149b2b4ca698d4f259f4054236 MONITOR_UNIT=meinfehlschlag.service Falls mysuccess.service ausgefuhrt und mit einem Fehlschlag beendet wurde, dann wurde myhandler.service ausgelost und die Uberwachungsvariablen wie folgt gesetzt: MONITOR_SERVICE_RESULT=success MONITOR_EXIT_CODE=exited MONITOR_EXIT_STATUS=0 MONITOR_INVOCATION_ID=6ab9af147b8c4a3ebe36e7a5f8611697 MONITOR_UNIT=meinerfolg.service SIEHE AUCH systemd(1), systemctl(1), systemd-analyze(1), journalctl(1), systemd-system.conf(5), systemd.unit(5), systemd.service(5), systemd.socket(5), systemd.swap(5), systemd.mount(5), systemd.kill(5), systemd.resource-control(5), systemd.time(7), systemd.directives(7), tmpfiles.d(5), exec(3), fork(2) ANMERKUNGEN 1. Spezifikation fur auffindbare Partitionen https://uapi-group.org/specifications/specs/discoverable_partitions_specification 2. Das /proc-Dateisystem https://docs.kernel.org/filesystems/proc.html#mount-options 3. Benutzer-/Gruppennamen-Syntax https://systemd.io/USER_NAMES 4. Schalter >>Keine neuen Privilegien<< https://docs.kernel.org/userspace-api/no_new_privs.html 5. JSON-Benutzerdatensatz https://systemd.io/USER_RECORD 6. Das /proc-Dateisystem https://docs.kernel.org/filesystems/proc.html 7. Kernel Samepage Merging https://docs.kernel.org/admin-guide/mm/ksm.html 8. Unicode Skalarwerte https://www.unicode.org/glossary/#unicode_scalar_value 9. Unicode-Nichtzeichen https://www.unicode.org/glossary/#noncharacter 10. Unicode-Byte-Reihenfolge-Markierung https://www.unicode.org/glossary/#byte_order_mark 11. POSIX-Shell-Text ohne Anfuhrungszeichen https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_01 12. POSIX-Shell-Text in einfachen Anfuhrungszeichen https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_02 13. POSIX-Shell-Text in doppelten englischen Anfuhrungszeichen https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02_03 14. Base64 https://tools.ietf.org/html/rfc2045#section-6.8 15. Container-Schnittstelle https://systemd.io/CONTAINER_INTERFACE 16. DMI/SMBIOS https://www.dmtf.org/standards/smbios 17. Qemu https://www.qemu.org/docs/master/system/index.html 18. System- und Dienste-Zugangsberechtigungen https://systemd.io/CREDENTIALS 19. Umgang mit Speicherdruck https://systemd.io/MEMORY_PRESSURE 20. LSB-Spezifikation https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 SYSTEMD.EXEC(5)