Die folgenden Einstellungen können zur Änderung der Sicht eines Dienstes auf das Dateisystem verwandt werden. Bitte beachten Sie, dass die Pfade absolut sein müssen und keine »..«-Pfadkomponente enthalten dürfen.
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 können.
ExecSearchPath= setzt
$PATH außer 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 anhängen.
Hinzugefügt 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 für ausgeführte Prozesse. Falls auf »~« gesetzt, wird das Home-Verzeichnis des in User= festgelegten Benutzers verwandt. Falls nicht gesetzt, ist dies standardmäßig das Wurzelverzeichnis, falls Systemd als eine Systeminstanz läuft und das Home-Verzeichnis des respektiven Benutzers, falls es als Benutzer läuft. Falls der Einstellung das Zeichen »-« vorangestellt wird, wird ein fehlendes Arbeitsverzeichnis nicht als fatal betrachtet. Falls RootDirectory=/RootImage= nicht gesetzt ist, dann ist WorkingDirectory= relativ zu der Wurzel des Systems, das den Diensteverwalter betreibt. Beachten Sie, dass das Setzen dieses Parameters die Hinzunahme von zusätzlichen Abhängigkeiten (siehe oben) auslösen kann.
RootDirectory=
Akzeptiert einen Verzeichnispfad, der relativ zum Wurzelverzeichnis des Rechners (d.h. der Wurzel des Systems, auf dem der Diensteverwalter läuft) ist. Setzt mit dem Systemaufruf
chroot(2) das Wurzelverzeichnis für ausgeführte Prozesse. Falls dies verwandt wird, muss sichergestellt werden, dass das Prozessprogramm und alle seine zugehörigen Dateien in dem
chroot()-Gefängnis verfügbar sind. Beachten Sie, dass das Setzen dieses Parameters die Hinzunahme von zusätzlichen Abhängigkeiten (siehe oben) auslösen kann.
Die Einstellungen MountAPIVFS= und PrivateUsers= sind inbesondere im Zusammenhang mit RootDirectory= nützlich. Für Details siehe unten.
Falls RootDirectory=/RootImage= zusammen mit NotifyAccess= verwandt werden, wird der Benachrichtigungs-Socket automatisch vom Rechner in die Wurzel-Umgebung eingehängt, um sicherzustellen, dass das Benachrichtigungs-Socket korrekt funktionieren kann.
Beachten Sie, dass Dienste, die RootDirectory=/RootImage= verwenden, nicht in der Lage sein werden, über das Syslog- oder Journal-Protokoll in die Protokollierinfrastruktur des Rechners zu protokollieren, außer die relevanten Sockets vom Rechner sind eingehängt, konkret:
Die Datei os-release(5) des Hauptsystems wird dem Dienst (schreibgeschützt) 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 überlebt.
Beispiel 1. Einhängen von Protokollier-Sockets in die Wurzel-Umgebung
BindReadOnlyPaths=/dev/log /run/systemd/journal/socket /run/systemd/journal/stdout
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
RootImage=
Akzeptiert einen Pfad zu einem Blockgeräteknoten oder einer regulären Datei als Argument. Dieser Aufruf ist ähnlich
RootDirectory=, hängt allerdings eine Dateisystemhierarchie aus einem Blockgeräteknoten oder einer Loopback-Datei anstatt eines Verzeichnisses ein. Der Geräteknoten oder die Dateisystemabbilddatei müssen ein Dateisystem ohne Partitionstabelle enthalten oder ein Dateisystem innerhalb einer MBR/MS-DOS- oder GPT-Partitionstabelle mit nur einer einzelnen Linux-kompatiblen Partition oder eine Gruppe von Dateisystemen innerhalb einer GPT-Partitionstabelle, die der
Spezifikation für auffindbare Partitionen[1] folgt.
Wenn DevicePolicy= auf »closed« oder »strict« gesetzt ist oder auf »auto« und DeviceAllow= gesetzt ist, dann fügt diese Einstellung /dev/loop-control mit Modus rw, »block-loop« und »block-blkext« mit Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) für die Details über DevicePolicy= oder DeviceAllow=. Siehe auch nachfolgendes PrivateDevices=, da sie die Einstellungen von DevicePolicy= ändern könnte.
Units, die RootImage= verwenden, erlangen automatisch eine After=-Abhängigkeit auf systemd-udevd.service.
Die Datei os-release(5) des Hauptsystems wird dem Dienst (schreibgeschützt) 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 überlebt.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt in Version 233.
RootImageOptions=
Akzeptiert eine Kommata-getrennte Liste von Einhängeoptionen, die bei mit
RootImage= angegebenen Plattenabbildern verwandt werden. Optional kann ein Partitionsname vorangestellt werden, gefolgt von einem Doppelpunkt, falls das Abbild über mehrere Partitionen verfügt, andernfalls wird der Partitionsname »root« angenommen. Optionen für mehrere Partitionen können 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) für eine Liste gültiger Einhängeoptionen.
Gültige Partitionsnamen folgen der Spezifikation für auffindbare Partitionen[1]: root, usr, home, srv, esp, xbootldr, tmp, var.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt in Version 247.
RootEphemeral=
Akzeptiert ein logisches Argument. Falls aktiviert, werden ausgeführte Prozesse in einer flüchtigen Kopie des Wurzelverzeichnisses oder Wurzelabbildes laufen. Die flüchtige Kopie liegt in /var/lib/systemd/ephemeral-trees/ während der Dienst aktiv ist und wird bereinigt, wenn der Dienst gestoppt oder neu gestartet wird. Falls
RootDirectory= verwandt wird und das Wurzelverzeichnis ein Unterdatenträger ist, wird die flüchtige Kopie durch Erstellen eines Schnappschusses des Unterdatenträgers erstellt.
Um sicherzustellen, dass flüchtige 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 Unterdatenträger sein, von dem systemd einen Schnappschuss zur Erstellung der flüchtigen Kopie schießen kann. Für Wurzelabbilder sollte ein Dateisystem mit Unterstützung für »reflinks« verwandt werden, um eine effiziente flüchtige Kopie sicherzustellen.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt in Version 254.
RootHash=
Akzeptiert einen hexadezimal angegebenen Datenintegritäts-Hash (dm-verity) für die Wurzel oder den Pfad zu einer Datei, die einen ASCII-hexadezimal-formatierten Hash der Wurzel enthält. Diese Option aktiviert Datenintegritätsüberprüfungen mittels dm-verity, falls das verwandte Abbild die geeigneten Integritätsdaten enthält (siehe oben) oder falls
RootVerity= verwandt wird. Der angegebene Hash muss auf den Wurzel-Hash der Integritätsdaten 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« trägt (siehe
xattr(7)EN), dann wird der Wurzel-Hash daraus gelesen, auch als hexdezimal formatierte Zeichen. Falls das erweiterte Dateiattribut nicht gefunden wird (oder vom zugrundeliegenden Dateisystem nicht unterstützt wird), aber eine Datei mit der Endung ».roothash« neben der Abbild-Datei gefunden wird, die anderweitig genau den gleichen Namen trägt (außer falls das Abbild die Endung ».raw« trägt, 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 für /usr/ enthält, könnte sie auch Verity-geschützt sein. In diesem Fall könnte der Wurzel-Hash auch über ein erweitertes Attribut »user.verity.usrhash« oder eine Datei .usrhash in der Nähe des Plattenabbildes konfiguriert sein. Derzeit gibt es keine Option, um den Wurzel-Hash für das Dateisystem /usr/ mittels der Unit-Datei direkt zu konfigurieren.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt 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-Datenträger wird nur geöffnet, falls die Signatur des Wuzel-Hashes gültig ist und von einem öffentlichen Schlüssel signiert wurde, der im Kernel-Schlüsselbund 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 trägt (außer falls das Abbild die Endung ».raw« trägt, 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 für /usr/ enthält, könnte sie auch Verity-geschützt sein. In diesem Fall könnte die Signatur für den Wurzel-Hash auch über eine Datei .usrhash.p7s in der Nähe des Plattenabbildes konfiguriert sein. Derzeit gibt es keine Option, um die Wurzel-Hash-Signatur für das Dateisystem /usr/ mittels der Unit-Datei direkt zu konfigurieren.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt in Version 246.
RootVerity=
Akzeptiert einen Pfad zu einer Datenintegritäts- (dm-verity-)Datei. Diese Option aktiviert Datenintegritätsüberprüfungen mittels dm-verity, falls
RootImage= verwandt wird und ein Wurzel-Hash übergeben wird und falls das verwandte Abbild selbst keine Integritätsdaten enthält. Die Integritätsdaten müssen 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 trägt (außer falls das Abbild die Endung ».raw« trägt, dann darf die Signaturdatei dies nicht in ihrem Namen haben), dann werden die Verity-Daten daraus gelesen und automatisch verwandt.
Diese Option wird nur für Plattenabbilder unterstützt, die ein einzelnes Dateisystem, ohne umhüllende 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 für auffindbare Partitionen[1] umsetzen.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt in Version 246.
RootImagePolicy=, MountImagePolicy=, ExtensionImagePolicy=
Akzeptiert eine Abbildrichtlinienzeichenkette gemäß
systemd.image-policy(7), die beim Einhängen eines in
RootImage=,
MountImage= bzw.
ExtensionImage= festgelegten Plattenabbildes verwandt werden soll. Falls sie nicht angegeben ist, ist die folgende Richtlinienzeichenkette die Vorgabe für
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 für ExtensionImagePolicy= ist:
root=verity+signed+encrypted+unprotected+absent: \
usr=verity+signed+encrypted+unprotected+absent Hinzugefügt in Version 254.
MountAPIVFS=
Akzeptiert ein logisches Argument. Falls eingeschaltet, wird ein privater Einhängenamensraum für die Prozesse der Unit erstellt und die API-Dateisysteme /proc/, /sys/, /dev/ und /run/ (als ein leeres »tmpfs«) darin eingehängt, außer sie sind bereits eingehängt. Beachten Sie, dass diese Option keinen Effekt zeigt, außer sie wird zusammen mit
RootDirectory=/
RootImage= verwandt, da diese vier Einhängungen im Allgemeinen im Rechner sowieso eingehängt sind und außer wenn das Wurzelverzeichnis geändert wird, der private Einhängenamensraum eine 1:1-Kopie des Rechners sein wird und diese vier Einhängungen enthalten wird. Beachten Sie, dass das /dev/-Dateisystem des Rechners mit »bind« eingehängt wird, falls diese Option ohne
PrivateDevices= verwandt wird. Um den Dienst mit einer privaten, minimalen Version von /dev/ auszuführen, kombinieren Sie diese Option mit
PrivateDevices=.
Um die sichere Einhängeausbreitung zur Laufzeit zu ermöglichen, wird auf dem Rechner /run/systemd/propagate/ zur Einrichtung neuer Einhängungen und im privaten Namensraum /run/host/incoming/ als Zwischenschritt verwandt, um diese zu speichern, bevor sie auf den endgültigen Einhängepunkt verschoben werden.
Hinzugefügt in Version 233.
ProtectProc=
Akzeptiert entweder »noaccess«, »invisible«, »ptraceable« oder »default« (die Vorgabe). Wenn gesetzt, steuert dies die Einhängeoption »hidepid=« der »procfs«-Instanz für die Unit, die steuert, welche Verzeichnisse mit Prozessmetainformationen (/proc/
PID) sichtbar und zugreifbar sind: wird dies auf »noaccess« gesetzt, dann wird die Fähigkeit, auf die meisten Prozessmetadaten anderer Prozesse in /proc/ zuzugreifen, für Prozesse des Dienstes entfernt. Wird dies auf »invisible« gesetzt, dann werden die meisten Prozesse, die anderen Benutzern gehören, in /proc/ versteckt. Bei »ptraceable« werden alle Prozesse, die nicht mit
ptrace() untersucht werden können, davor versteckt. Bei »default« werden keine Einschränkungen beim Zugriff auf /proc/ oder dessen Sichtbarkeit vorgenommen. Für weitere Details siehe
Das /proc-Dateisystem[2]. Es wird im Allgemeinen empfohlen, die meisten Systemdienste so auszuführen, dass diese Option auf »invisible« gesetzt ist. Diese Option wird mittels Dateisystemnamensräumen implementiert und kann daher nicht mit Diensten verwandt werden, die in der Lage sein müssen, Einhängepunkte 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 Funktionalität zu umgehen. Sie kann nicht für Dienste verwandt werden, die auf Metainformationen von Prozessen anderer Benutzer zugreifen müssen. Diese Option impliziert
MountAPIVFS=.
Falls der Kernel keine einhängepunktbezogenen Einhängeoptionen hidepid= unterstützt, 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 wäre.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt in Version 247.
ProcSubset=
Akzeptiert »all« (die Vorgabe) und »pid«. Falls »pid«, werden alle Dateien und Verzeichnisse, die nicht direkt der Prozessverwaltung und -prüfung zugeordnet sind, im Dateisystem /proc/, das für diese Prozesse konfiguriert wird, unsichtbar gemacht. Das steuert die Einhängeoption »subset=« der Instanz »procfs« für diese Unit. Für weitere Details siehe
Das /proc-Dateisystem[2]. Beachten Sie, dass Linux verschiedene Kernel-APIs über /proc/ offenlegt, die durch diese Einstellung unverfügbar gemacht werden. Da diese APIs häufig verwandt werden, ist diese Option nur in wenigen, besonderen Fällen nützlich und nicht für die meisten nicht-trivialen Programme geeignet.
Ganz ähnlich zu obigem ProtectProc= wird dies mittels Namensräumen für Dateisysteme implementiert und daher gelten die gleichen Einschränkungen: es ist nur für Systemdienste verfügbar und deaktiviert die Einhängeweiterleitung an die Einhängetabelle des Rechners und es implementiert MountAPIVFS=. Diese Einstellung wird wie bei ProtectProc= auch sauber beendet, falls der Kernel die Einhängeoption »subset=« von »procfs« nicht unterstützt..
Hinzugefügt in Version 247.
BindPaths=, BindReadOnlyPaths=
Konfiguriert Unit-spezifische Bind-Einhängungen. Eine Bind-Einhängung macht eine bestimmte Datei oder Verzeichnis an einem zusätzlichen Ort in der Betrachtung der Unit verfügbar. Alle mit dieser Option erstellten Bind-Einhängungen sind für die Unit spezifisch und nicht innerhalb der Einhängetabelle des Rechners sichtbar. Diese Option erwartet eine Leerraum-getrennte Liste von Bind-Einhängedefinitionen. Jede Definition besteht aus einem durch Doppelpunkte getrennten Tripel von Quellpfad, Zielpfad und Optionszeichenkette, wobei die letzteren zwei optional sind. Falls nur ein Quellpfad festgelegt wird, wird angenommen, dass Quelle und Ziel identisch sind. Die Optionszeichenkette kann entweder »rbind« oder »norbind« sein, um eine rekursive oder nichtrekursive Bind-Einhängung zu konfigurieren. Falls der Zielpfad ausgelassen wird, muss auch die Optionszeichenkette ausgelassen werden. Jeder Bind-Einhängungsdefinition kann »-« vorangestellt werden, wodurch sie ignoriert wird, falls der Quellpfad nicht existiert.
BindPaths= erstellt reguläre, schreibbare Bind-Einhängungen (außer die Quelldateisystemeinhängung ist bereits nur-lesbar markiert), während BindReadOnlyPaths= nur-lesbare Bind-Einhängungen erstellt. Diese Einstellungen können mehr als einmal verwandt werden, jede Verwendung hängt sich an die Liste der Bind-Einhängungen der Unit an. Falls zu einer dieser zwei Optionen die leere Zeichenkette zugewiesen wird, wird die gesamte Liste an vorher definierten Bind-Einhängungen dazu zurückgesetzt. Beachten Sie, dass in diesem Fall sowohl die nur-lesbaren als auch die regulären Bind-Einhängungen zurückgesetzt werden, unabhängig davon, welche der zwei Einhängungen verwandt wird.
Diese Option ist besonders nützlich, wenn RootDirectory=/RootImage= verwandt wird. In diesem Fall bezieht sich der Quellpfad auf einen Pfad im Dateisystem des Rechners, während der Zielpfad sich auf einen Pfad unterhalb des Wurzelverzeichnisses der Unit bezieht.
Beachten Sie, dass das Zielverzeichnis existieren oder Systemd in der Lage sein muss, es zu erstellen. Daher ist es nicht möglich, diese Option für Einhängepunkte, die unterhalb von in InaccessiblePaths= oder unter /home/ und anderen geschützten Verzeichnissen verschachtelt sind, zu verwenden, falls ProtectHome=yes angegeben ist. Stattdessen sollte TemporaryFileSystem= mit »:ro« oder ProtectHome=tmpfs verwandt werden.
Hinzugefügt in Version 233.
MountImages=
Diese Einstellung ist ähnlich zu
RootImage=. Sie hängt eine Dateisystemhierarchie von einem Blockgeräteknoten oder Loopack-Geräte ein, aber das Ziel-Verzeichnis sowie die Einhängeoptionen können angegeben werden. Diese Option erwartet ein durch Leerraum getrennte Liste von Einhängedefinitionen. Jede Definition besteht aus einem Doppelpunkt-getrennten Tupel von Quellpfad- und -Ziel-Definitionen, optional gefolgt durch einen weiteren Doppelpunkt und einer Liste von Einhängeoptionen.
Einhängeoptionen können 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 Einhängeoptionen angegeben werden. Gültige Partitionsnamen und -Einhängeoptionen sind zu der oben beschriebenen Einstellung RootImageOptions= identisch.
Jeder Einhängedefinition darf ein »-« vorangestellt werden. In diesem Fall wird sie ignoriert, falls sein Quellpfad nicht existiert. Das Quellargument ist ein Pfad zu einem Blockgeräteknoten oder einer regulären Datei. Falls die Quelle oder das Ziel ein »:« enthält, muss dieses mit »\:« maskiert werden. Der Geräteknoten oder das Dateisystemabbild muss den gleichen Regeln folgen, wie diese für RootImage= spezifiziert sind. Alle Einhängungen, die mit dieser Option erstellt sind, sind spezifisch für die Unit, und können in der Einhängetabelle des Rechners nicht gesehen werden.
Diese Einstellung kann mehr als einmal verwandt werden. Jede Verwendung wird an die Liste der Einhängepfade der Unit angehängt. Falls die leere Zeichenkette zugewiesen wird, wird die gesamte Liste der Einhängepfade, die vorher definiert wurde, zurückgesetzt.
Beachten Sie, dass das Zielverzeichnis existieren oder Systemd in der Lage sein muss, es zu erstellen. Daher ist es nicht möglich, diese Option für Einhängepunkte, die unterhalb von in InaccessiblePaths= oder unter /home/ und anderen geschützten Verzeichnissen verschachtelt sind, zu verwenden, falls ProtectHome=yes angegeben ist.
Wenn DevicePolicy= auf »closed« oder »strict« gesetzt ist oder auf »auto« und DeviceAllow= gesetzt ist, dann fügt diese Einstellung /dev/loop-control mit Modus rw, »block-loop« und »block-blkext« mit Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) für die Details über DevicePolicy= oder DeviceAllow=. Siehe auch nachfolgendes PrivateDevices=, da sie die Einstellungen von DevicePolicy= ändern könnte.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt in Version 247.
ExtensionImages=
Diese Einstellung ist ähnlich zu
MountImages=. Sie hängt eine Dateisystemhierarchie von einem Blockgeräteknoten oder Loopack-Geräte ein, aber anstatt ein Ziel-Verzeichnis bereitzustellen, wird eine Überlagerung eingerichtet. Diese Option erwartet eine durch Leerraum getrennte Liste von Einhängedefinitionen. Jede Definition besteht aus einem Quellpfad, optional gefolgt von einem Doppelpunkt und einer Liste von Einhängeoptionen.
Es wird ein nur lesbares OverlayFS oberhalb der Hierarchien /usr/ und /opt/ für Sysext-Abbilder und der Hierarchie /etc/ für Confext-Abbilder eingerichtet. Die Reihenfolge, in der die Abbilder aufgeführt sind, wird die Reihenfolge bestimmen, in der die Überlagerung aufgebaut ist: das zuerst angegebene Abbild ist auf unterster Ebene im OverlayFS und spätere sind entsprechend darüber bis ganz oben.
Einhängeoptionen können 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 Einhängeoptionen angegeben werden. Gültige Partitionsnamen und -Einhängeoptionen sind zu der oben beschriebenen Einstellung RootImageOptions= identisch.
Jeder Einhängedefinition darf ein »-« vorangestellt werden. In diesem Fall wird sie ignoriert, falls sein Quellpfad nicht existiert. Das Quellargument ist ein Pfad zu einem Blockgeräteknoten oder einer regulären Datei. Falls der Quellpfad ein »:« enthält, muss dieses mit »\:« maskiert werden. Der Geräteknoten oder das Dateisystemabbild muss den gleichen Regeln folgen, wie diese für RootImage= spezifiziert sind. Alle Einhängungen, die mit dieser Option erstellt sind, sind spezifisch für die Unit, und können in der Einhängetabelle des Rechners nicht gesehen werden.
Diese Einstellung kann mehr als einmal verwandt werden. Jede Verwendung wird an die Liste der Abbildpfade der Unit angehängt. Falls die leere Zeichenkette zugewiesen wird, wird die gesamte Liste der Einhängepfade, die vorher definiert wurde, zurückgesetzt.
Jede Sysext-Abbilddatei muss eine Datei /usr/lib/extension-release.d/extension-release.IMAGE transportieren, während Confext-Abbilder eine Datei /etc/extension-release.d/extension-release.IMAGE transportieren müssen, mit den geeigneten Metadaten, die auf RootImage=/RootDirectory= oder den Rechner passen. Siehe os-release(5). Um die Sicherheitsüberprüfung, dass der Dateiname der Erweiterungs-Release-Datei auf den Namen der Abbild-Datei passt, zu deaktivieren, kann die Einhängeoption x-systemd.relax-extension-release-check angehängt werden.
Wenn DevicePolicy= auf »closed« oder »strict« gesetzt ist oder auf »auto« und DeviceAllow= gesetzt ist, dann fügt diese Einstellung /dev/loop-control mit Modus rw, »block-loop« und »block-blkext« mit Modus rwm zu DeviceAllow= hinzu. Siehe systemd.resource-control(5) für die Details über DevicePolicy= oder DeviceAllow=. Siehe auch nachfolgendes PrivateDevices=, da sie die Einstellungen von DevicePolicy= ändern könnte.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt in Version 248.
ExtensionDirectories=
Diese Einstellung ist ähnlich zu
BindReadOnlyPaths=. Sie hängt eine Dateisystemhierarchie von einem Verzeichnis ein, aber anstatt ein Ziel-Verzeichnis bereitzustellen, wird eine Überlagerung eingerichtet. Diese Option erwartet eine durch Leerraum getrennte Liste von Quellverzeichnissen.
Es wird ein nur lesbares OverlayFS oberhalb der Hierarchien /usr/ und /opt/ für Sysext-Abbilder und oberhalb der Hierarchie /etc/ für Confext-Abbilder eingerichtet. Die Reihenfolge, in der die Verzeichnisse aufgeführt sind, wird die Reihenfolge bestimmen, in der die Überlagerung aufgebaut ist: das zuerst angegebene Verzeichnis ist auf unterster Ebene im OverlayFS und spätere sind entsprechend darüber bis ganz oben.
Jedem in ExtensionDirectories= aufgeführten Verzeichnis darf ein »-« vorangestellt werden. In diesem Fall wird es ignoriert, falls sein Quellpfad nicht existiert. Alle Einhängungen, die mit dieser Option erstellt sind, sind spezifisch für die Unit, und können in der Einhängetabelle des Rechners nicht gesehen werden.
Diese Einstellung kann mehr als einmal verwandt werden. Jede Verwendung wird an die Liste der Verzeichnispfade der Unit angehängt. Falls die leere Zeichenkette zugewiesen wird, wird die gesamte Liste der Einhängepfade, die vorher definiert wurde, zurückgesetzt.
Jedes Sysext-Verzeichnis muss eine Datei /usr/lib/extension-release.d/extension-release.IMAGE enthalten, während 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 Unterstützung von Overlayfs in nicht privilegierten Benutzernamensräumen benötigt, welche erstmalig in Kernel v5.11. eingeführt wurde.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt in Version 251.
LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, LimitRTPRIO=, LimitRTTIME=
Setzt die weichen und harten Beschränkungen für verschiedene Ressourcen für ausgeführte Prozesse. Siehe
setrlimit(2)EN für Details über das Prozessressourcen-Begrenzungskonzept. Prozessressourcenbegrenzungen können in zwei Formaten festgelegt werden: entweder als einzelner Wert, um eine bestimmte weiche und harte Begrenzung auf den gleichen Wert zu setzen, oder als Doppelpunkt-getrenntes Paar
weich:hart, um beide Begrenzungen individuell zu setzen (z.B. »LimitAS=4G:16G«). Verwenden Sie die Zeichenkette
infinity, um keine Begrenzung für eine bestimmte Ressource zu konfigurieren. Die multiplikativen Endungen K, M, G, T, P und E (auf Basis 1024) können für Ressourcenbegrenzungen, die in Bytes gemessen werden, verwandt werden (z.B. »LimitAS=16G«). Für Begrenzungen, die sich auf Zeitwerte beziehen, können die im Englischen normalen Zeiteinheiten ms, s, min, h und so weiter verwandt werden (siehe
systemd.time(7) für Details). Beachten Sie, dass die Standardzeiteinheit als Sekunden impliziert ist, falls keine Zeiteinheit für
LimitCPU= angegeben ist. Für
LimitRTTIME= wird als Standardeinheit Mikrosekunden impliziert. Beachten Sie, dass die effektive Granularität der Begrenzungen ihre Durchsetzung beeinflussen könnte. Beispielsweise werden für
LimitCPU= festgelegte Zeitbeschränkungen implizit auf Vielfache von 1s aufgerundet. Für
LimitNICE= kann der Wert in zwei Syntaxen festgelegt werden: falls ihm »+« oder »-« vorangestellt wird, wird der Wert als regulärer Linux-Nice-Wert im Bereich -20…19 interpretiert. Falls ihm so etwas nicht vorangestellt wird, wird der Wert als roher Ressourcenbegrenzungsparameter im Bereich 0…40 (wobei 0 äquivalent zu 1 ist) verstanden.
Beachten Sie, dass die meisten der mit diesen Optionen konfigurierten Ressourcenbeschränkungen prozessbezogen sind. Prozesse können einen Fork durchführen, um einen neuen Satz an Ressourcen zu erlangen. Diese neuen Ressourcen können unabhängig vom ursprünglichen Prozess verbucht werden und daher gesetzten Beschränkungen entkommen.Beachten Sie auch, dass LimitRSS= unter Linux nicht implementiert ist und das Setzen keinen Effekt hat. Oft ist es ratsam, die in systemd.resource-control(5) aufgeführten Ressourcensteuerungen gegenüber den prozessabhängigen zu bevorzugen, da sie, auf Dienste als ganzes angewandt, zur Laufzeit verändert werden und im Allgemeinen ausdrucksstärker sind. Beispielsweise ist MemoryMax= ein leistungsfähigerer (und funktionierender) Ersatz für 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 für alle unter der gleichen UID laufenden Prozesse kumulierend. Bitte beachten Sie auch, dass LimitNPROC= nicht durchgesetzt wird, falls der Dienst als root läuft (und seine Privilegien nicht abgibt). Aufgrund dieser Einschränkungen ist TasksMax= (siehe systemd.resource-control(5)) typischerweise eine bessere Wahl als LimitNPROC=.
Nicht explizit konfigurierte Ressourcenbeschränkungen für eine Unit verwenden als Vorgabe die in den verschiedenen in systemd-system.conf(5) verfügbaren Optionen DefaultLimitCPU=, DefaultLimitFSIZE=, … konfigurierten Werte und – falls sie dort nicht konfiguriert sind – die Kernel- oder benutzerbezogenen Vorgaben, wie sie durch das Betriebssystem (Letzteres nur für Benutzerdienste, siehe unten) definiert sind.
Für System-Units können diese Ressourcenbeschränkungen frei gewählt werden. Wenn diese Einstellungen in einem Benutzerdienst (d.h. einem Dienst, der von der benutzerbezogenen Instanz des Diensteverwalters ausgeführt wird) konfiguriert sind, können sie nicht zum Anheben der Beschränkungen über die Werte, die für den Benutzerverwalter beim ersten Aufruf selbst gesetzt sind, verwandt werden, da dem Benutzerverwalter im Allgemeinen hierfür die Privilegien fehlen. Im Benutzerkontext sind diese Konfigurationsoptionen daher nur nützlich, um die hereingegebenen Beschränkungen zu senken oder für den Benutzer konfigurierten weichen Beschränkungen maximal auf die harten Beschränkungen anzuheben. Um die Benutzerbeschränkungen weiter anzuheben, unterscheiden sich die verfügbaren Konfigurationsmechanismen zwischen Betriebssystemen, benötigen aber typischerweise Privilegien. In den meisten Fällen ist es möglich, höhere benutzerbezogene Ressourcenbeschränkungen mittels PAM zu konfigurieren oder durch Setzen von Beschränkungen 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 Änderungen vorgenommen haben.
Tabelle 1. Ressourcenbegrenzungsanweisungen, ihre äquivalenten Ulimit-Shell-Befehle und die verwandte Einheit
| Anweisung | ulimit-Äquivalent | Einheit | Hinweise |
| LimitCPU= | ulimit -t | Sekunden | - |
| LimitFSIZE= | ulimit -f | Bytes | - |
| LimitDATA= | ulimit -d | Bytes | Nicht verwenden. Diese beschränkt den erlaubten Adressbereich, nicht die Speicherverwendung! Standardmäßig unbeschränkt und sollte nicht gesenkt werden. Um die Speicherverwendung zu beschränken, 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 Dateideskriptoren | Nicht verwenden. Seien Sie beim Anheben der weichen Begrenzung über 1024 vorsichtig, da unter Linux select(2) nicht mit Dateideskriptoren über 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 selbständig auf die harte Begrenzung anheben, falls sie mit Dateideskriptoren oberhalb von 1023 umgehen können, 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, einschließlich des Speichers für Dateideskriptoren. |
| LimitAS= | ulimit -v | Bytes | Nicht verwenden. Diese beschränkt den erlaubten Adressbereich, nicht die Speicherverwendung! Standardmäßig unbeschränkt und sollte nicht gesenkt werden. Um die Speicherverwendung zu beschränken, siehe MemoryMax= in systemd.resource-control(5). |
| LimitNPROC= | ulimit -u | Anzahl an Prozessen | Diese Beschränkung wird basierend auf der Anzahl der dem Benutzer gehörenden 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 | Echtzeitpriorität | - |
| LimitRTTIME= | ulimit -R | Mikrosekunden | - |
UMask=
Steuert die Dateimoduserstellungsmaske. Akzeptiert einen Zugriffsmodus in oktaler Notation. Siehe
umask(2) für Details. Standardmäßig 0022 für System-Units. Für Benutzer-Units wird der Vorgabewert von dem benutzerbezogenen Diensteverwalter geerbt (dessen Vorgabewert wiederum vom Systemdiensteverwalter geerbt wird, und daher typischerweise auch 0022 ist — außer dies wurde von einem PAM-Modul außer Kraft gesetzt). Um die benutzerbezogene Maske für alle Benutzerdienste zu ändern, 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 (für Benutzer, die mittels
systemd-homed.service(8) verwaltet werden, kann dieses Feld auch über
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 durchführt (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)EN für 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 geändert.
Beispiel 2. DAX-Seiten zum Speicherauszugsfilter hinzufügen
CoredumpFilter=default private-dax shared-dax
Hinzugefügt in Version 246.
KeyringMode=
Steuert, wie der Kernelsitzungsschlüsselbund für den Dienst eingerichtet wird (siehe
session-keyring(7) für Details über den Sitzungsschlüsselbund). Akzeptiert einen aus
inherit,
private,
shared. Falls auf
inherit gesetzt, wird keine besondere Schlüsselbundeinrichtung vorgenommen und das Standardverhalten des Kernels wird angewandt. Falls
private verwandt wird, wird ein neuer Sitzungsschlüsselbund bereitgestellt, wenn ein Diensteprozess aufgerufen wird und dieser nicht mit einem Benutzerschlüsselbund verbunden ist. Dies ist die für Systemdienste empfohlene Einstellung, da sie sicherstellt, dass mehrere Dienste, die unter der gleichen Systembenutzerkennung laufen (insbesondere des Benutzers root) ihr Schlüsselmaterial nicht gemeinsam benutzen. Falls
shared verwandt wird, wird ein neuer Schlüsselbund wie für
private reserviert, aber der Benutzerschlüsselbund des mit
User= konfigurierten Benutzers wird mit eingebunden, so dass die dem Benutzer zugeordneten Schlüssel von den Prozessen der Unit angefragt werden können. In diesem Modus können mehrere Units, die Prozesse unter der selben Benutzerkennung ausführen, Schlüsselmaterial gemeinsam benutzen. Außer bei der Auswahl von
inherit wird die eindeutige Aufrufkennung für die Unit (siehe unten) als geschützter Schlüssel unter dem Namen »invocation_id« zu dem neu erstellten Sitzungsschlüsselbund hinzugefügt. Standardmäßig
private für Dienste des Systemdiensteverwalters und
inherit für nicht Dienste-Units und für Dienste des Benutzerdiensteverwalters.
Hinzugefügt in Version 235.
OOMScoreAdjust=
Setzt den Anpassungswert für die Speicherknappheit- (OOM-)Killer-Bewertung des Kernels für ausgeführte Prozesse. Akzeptiert eine Ganzzahl zwischen -1000 (um das OOM-Töten von Prozessen dieser Unit zu deaktivieren) und 1000 (womit das Töten von Prozessen dieser Unit bei Speicherdruck sehr wahrscheinlich wird). Siehe
Das /proc-Dateisystem[6] für 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) für Details.
TimerSlackNSec=
Setzt den Timer-Spielraum in Nanosekunden für den ausgeführten Prozess). Der Timer-Spielraum steuert die Genauigkeit der durch Systemd-Timer ausgelösten Aufwachaktionen. Siehe
prctl(2)EN für weitere Informationen. Beachten Sie, dass im Gegensatz zu den meisten anderen Zeitdauerdefinitionen dieser Parameter einen Ganzzahlwert in Nanosekunden akzeptiert, falls keine Einheit angegeben ist. Es werden auch die normalen Zeiteinheiten verstanden.
Personality=
Steuert, welche Kernelarchitektur
uname(2) melden soll, wenn es von Unit-Prozessen aufgerufen wird. Akzeptiert eine der Architekturkennungen
arm64,
arm64-be,
arm,
arm-be,
x86,
x86-64,
ppc,
ppc-le,
ppc64,
ppc64-le,
s390 oder
s390x. Welche Personalitätsarchitekturen unterstützt werden, hängt von der nativen Architektur des Kernels ab. Normalerweise unterstützen die 64-Bit-Versionen der verschiedenen Systemarchitekturen die direkte Entsprechung der 32-Bit-Personalitätsarchitektur, aber keine anderen. Beispielsweise unterstützen
x86-64-Systeme die
x86-64- und
x86-Personalitäten, aber keine anderen. Die Personalitätsfunktionalität ist nützlich, wenn 32-Bit-Dienste auf einem 64-Bit-System ausgeführt werden. Falls nicht angegeben, wird die Personalität nicht verändert und spiegelt daher die Personalität des Systemkernels wider. Diese Option ist auf Architekturen nicht nützlich, für die nur eine native Wortbreite jemals verfügbar war, wie
m68k (nur 32 bit) oder
alpha (nur 64 bit).
Hinzugefügt in Version 209.
IgnoreSIGPIPE=
Akzeptiert ein logisches Argument. Falls wahr, wird SIGPIPE in dem ausgeführten Prozess ignoriert. Standardmäßig wahr, da SIGPIPE im Allgemeinen nur in Shell-Pipes nützlich ist.
Die nachfolgenden Sandboxing-Optionen bieten eine wirksame Art, die Kontakte des Systems im Hinblick auf die Prozesse der Unit zu begrenzen. Es wird empfohlen, so viele dieser Optionen wie möglich, ohne die Betriebsfähigkeit der Prozesse der Unit negativ zu betreffen, einzuschalten. Beachten Sie, dass viele dieser Sandboxing-Funktionalitäten beschwerdefrei auf Systemen, auf denen der unterliegende Sicherheitsmechanismus nicht verfügbar ist, ausgeschaltet werden. Beispielsweise hat ProtectSystem= keine Wirkung, falls der Kernel ohne Namensräume für Dateisysteme gebaut wurde oder falls der Diensteverwalter in einem Container-Verwalter ausgeführt wird, der dafür sorgt, dass Dateisystem-Namensräume für seine Nutzlast nicht verfügbar sind. Ähnlich hat RestrictRealtime= auf Systemen keine Wirkung, denen die Unterstützung für SECCOMP-Systemaufruffilterung fehlt oder in Containern, in denen die Unterstützung dafür abgeschaltet ist.
Beachten Sie auch, dass einige Sandboxing-Funktionalität im Allgemeinen in Benutzerdiensten (d.h. Diensten, die vom benutzerbezogenen Diensteverwalter ausgeführt werden) nicht verfügbar ist. Insbesondere die verschiedenen Einstellungen, die die Unterstützung für Dateisystem-Namensräume benötigen (wie ProtectSystem=) sind nicht verfügbar, da die zugrundeliegende Kernelfunktionalität nur für privilegierte Prozesse erreichbar ist. Allerdings werden die meisten Namensraum-Einstellungen, die nicht in ihrem eigenen Benutzerdienst funktionieren, bei der Verwendung zusammen mit PrivateUsers=true funktionieren.
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) für von dieser Unit aufgerufene Prozesse nur lesbar eingehängt. Falls auf »full« gesetzt, wird auch das Verzeichnis /etc/ nur lesbar eingehängt. Falls auf »strict« gesetzt, wird die gesamte Dateisystemhierarchie nur lesbar eingehängt, außer der API-Dateisystemunterbäume /dev/, /proc/ und /sys/ (schützen Sie diese Verzeichnisse mittels
PrivateDevices=,
ProtectKernelTunables=,
ProtectControlGroups=). Diese Einstellung stellt sicher, dass alle Änderungen an dem vom Lieferanten bereitgestellten Betriebssystem (und optional seiner Konfiguration und lokaler Einhängungen) für den Dienst verboten sind. Es wird empfohlen, diese Einstellung für alle langlaufenden Dienste zu aktivieren, außer sie sind an Systemaktualisierungen beteiligt oder müssen das Betriebssystem auf eine andere Art verändern. Falls diese Option verwandt wird, kann
ReadWritePaths= verwandt werden, um bestimmte Verzeichnisse von dem nur lesbaren Verhalten auszunehmen. Diese Einstellung ist impliziert, falls
DynamicUser= gesetzt ist. Diese Einstellung kann nicht für alle Fälle den Schutz sicherstellen. Im Allgemeinen hat es die gleichen Begrenzungen wie
ReadOnlyPaths=, siehe unten. Standardmäßig aus.
Hinzugefügt 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 für von der Unit aufgerufene Prozesse leer. Falls auf »read-only« gesetzt, werden die drei Verzeichnisse stattdessen nur lesbar gesetzt. Falls auf »tmpfs« gesetzt, werden temporäre Dateisysteme auf diesen drei Verzeichnissen im nur-lesbaren Modus eingehängt. Der Wert »tmpfs« ist nützlich, um Home-Verzeichnisse, die für die von der Unit aufgerufenen Prozesse nicht relevant sind, zu verstecken, während gleichzeitig notwendige Verzeichnisse weiterhin sichtbar gemacht werden können, indem sie mit
BindPaths= oder
BindReadOnlyPaths= aufgelistet werden.
Setzen dieser Einstellung auf »yes« ist fast äquivalent zum Setzen der drei Verzeichnisse in InaccessiblePaths=. Ähnlich ist »read-only« fast äquivalent zu ReadOnlyPaths= und »tmpfs« ist fast äquivalent zu TemporaryFileSystem= mit »:ro«.
Es wird empfohlen, diese Einstellung für alle langlaufenden Dienste (insbesondere solchen zu Netzen) zu aktivieren, um sicherzustellen, dass sie keinen Zugriff auf private Benutzerdaten bekommen, außer der Dienst benötigt tatsächlich Zugriff auf die privaten Daten der Benutzer. Diese Einstellung ist impliziert, falls DynamicUser= gesetzt ist. Diese Einstellung kann nicht für alle Fälle den Schutz sicherstellen. Im Allgemeinen hat es die gleichen Begrenzungen wie ReadOnlyPaths=, siehe unten.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt in Version 214.
RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory=
Diese Optionen akzeptieren eine Leerraum-getrennte Liste von Verzeichnisnamen. Die angegebenen Verzeichnisnamen müssen relativ sein und dürfen »..« 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 (einschließlich ihrer Eltern), wenn die Unit gestartet wird. Auch wird die entsprechende Umgebungsvariable mit dem vollständigen Pfad der Verzeichnisse definiert. Falls mehrere Verzeichnisse gesetzt sind, dann werden die Pfade in der Umgebungsvariablen mit dem Doppelpunkt (»:«) verkettet.
Tabelle 2. Automatische Verzeichniserstellung und Umgebungsvariablen
| Verzeichnis | Unterhalb vom Pfad von System-Units | Unterhalb vom Pfad von Benutzer-Units | Umgebungsvariablenmenge |
| 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 möglich, in diesem Fall die festgelegten Verzeichnisse zu erhalten, falls RuntimeDirectoryPreserve= auf restart oder yes konfiguriert ist (siehe unten). Die mit StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= festgelegten Verzeichnisse werden nicht entfernt, wenn die Unit gestoppt wird.
Außer im Fall von ConfigurationDirectory= werden die innersten festgelegten Verzeichnisse dem in User= und Group= angegebenem Benutzer und der Gruppe gehören. 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 geändert, so dass die Eigentümerschaft auf die konfigurierte passt. Falls die angegebenen Verzeichnisse bereits dem richtigen Benutzer und der richtigen Gruppe gehören, werden als Optimierung alle Dateien und Verzeichnisse darunter unverändert gelassen, selbst falls sie nicht auf das angeforderte passen. Die Zugriffsmodi der innersten angegebenen Verzeichnisse wird auf das, was in RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= und ConfigurationDirectoryMode= festgelegt ist, angepasst.
Diese Optionen implizieren BindPaths= für die festgelegten Pfade. Bei der Kombination mit RootDirectory= oder RootImage= werden diese Pfade immer innerhalb des Rechners liegen und von dort in den Dateisystemnamensraum der Unit eingehängt.
Falls DynamicUser= verwandt wird, ändert sich die Logik für 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 für nicht privilegierte Benutzer nicht zugreifbar sind. Dadurch wird sichergestellt, dass Zugriff auf diese Verzeichnisse nicht über die Wiederverwendung dynamischer Benutzerkennungen möglich ist. Symbolische Links werden erstellt, um diese Unterschiede im Verhalten zu verstecken. Daher tauchen sowohl aus Sicht des Rechners als auch aus innerhalb der Unit die relevanten Verzeichnisse immer direkt unter /var/cache, /var/log und /var/lib auf.
Verwenden Sie RuntimeDirectory=, um eine oder mehrere Laufzeitverzeichnisse für die Unit zu verwalten und ihre Lebensdauer an die Lebensdauer des Daemons zu koppeln. Dies ist insbesonders für nicht privilegierte Daemons nützlich, die aufgrund fehlender Privilegien keine Laufzeitverzeichnisse in /run/ erstellen können und um sicherzustellen, dass die Laufzeitverzeichnisse nach der Verwendung automatisch bereinigt werden. Für Laufzeitverzeichnisse, die eine komplexere oder andere Konfiguration oder Lebensdauergarantie benötigen, prüfen Sie den Einsatz von tmpfiles.d(5).
RuntimeDirectory=, StateDirectory=, CacheDirectory= und LogsDirectory= unterstützen 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 flüchtige Symlinks zu ermöglichen. 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 benötigt, muss ein anderer Mechanismus zu deren Erstellung verwandt werden.
tmpfiles.d(5) stellt Funktionalität bereit, die sich mit diesen Optionen überlappt. Es wird empfohlen, dass diese Optionen eingesetzt werden, da die Lebensdauer der Verzeichnisse an die Lebensdauer der Unit gekoppelt ist, und es nicht notwendig ist, sicherzustellen, dass die tmpfiles.d-Konfiguration vor dem Start der Unit ausgeführt wird.
Um alle von diesen Einstellungen erzeugten Verzeichnisse zu entfernen, verwenden Sie den Befehl systemctl clean … auf die relevanten Units, siehe systemctl(1) für Details.
Beispiel: Falls eine Systemdienste-Unit
RuntimeDirectory=foo/bar baz
enthält, erstellt der Diensteverwalter /run/foo (falls es noch nicht existiert), /run/foo/bar und /run/baz. Die Verzeichnisse /run/foo/bar und /run/baz außer /run/foo gehören dem Benutzer und der Gruppe, die in User= und Group= angegeben sind und werden entfernt, wenn der Dienst gestoppt wird.
Beispiel: Falls eine Systemdienste-Unit
RuntimeDirectory=foo/bar
StateDirectory=aaa/bbb ccc
enthält, dann wird die Umgebungsvariable »RUNTIME_DIRECTORY« mit »/run/foo/bar« und »STATE_DIRECTORY« mit »/var/lib/aaa/bbb:/var/lib/ccc« gesetzt.
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.
Hinzugefügt 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. Standardmäßig
0755. Siehe »Permissions« in
path_resolution(7) für eine Diskussion über die Benennung der Berechtigungs-Bits.
Hinzugefügt 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 ausgelöste. Falls auf
yes gesetzt, werden die Verzeichnisse nicht entfernt, wenn der Dienst beendet wird. Beachten Sie, dass die in
RuntimeDirectory= festgelegten Verzeichnisse entfernt werden, wenn das System neu gestartet wird, da das Laufzeitverzeichnis /run/ ein »tmpfs«-Einhängepunkt ist.
Hinzugefügt in Version 235.
TimeoutCleanSec=
Konfiguriert für die mittels
systemctl clean … erbetene Aufräumaktion eine Zeitüberschreitung, siehe
systemctl(1) für Details. Akzeptiert die gewöhnlichen Zeitwerte und ist standardmäßig
infinity, d.h. standardmäßig wird keine Zeitüberschreitung angewandt. Falls eine Zeitüberschreitung konfiguriert ist, wird die Aufräumaktion zwangsweise beendet, wenn die Zeitüberschreitung erreicht ist, möglicherweise verbleiben dann Ressourcen auf der Platte.
Hinzugefügt in Version 244.
ReadWritePaths=, ReadOnlyPaths=, InaccessiblePaths=, ExecPaths=, NoExecPaths=
Richtet einen neuen Dateisystemnamensraum für ausgeführte Prozesse ein. Diese Optionen können 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 ausführt) ist. Beachten Sie, dass die Pfade relativ zu dem mit
RootDirectory=/
RootImage= gesetzten Wurzelverzeichnis aufgelöst werden, falls sie Symlinks enthalten.
In ReadWritePaths= aufgeführte Pfade sind von innerhalb des Namensraums mit den gleichen Zugriffsmodi wie von außerhalb zugreifbar. Auf in ReadOnlyPaths= aufgeführte Pfade kann nur lesend zugegriffen werden, Schreiben wird abgelehnt, selbst falls die normale Dateizugriffssteuerung dies erlauben würde. Schachteln Sie ReadWritePaths= innerhalb von ReadOnlyPaths=, um schreibbare Unterverzeichnisse innerhalb nur lesbarer Verzeichnisse bereitzustellen. Verwenden Sie ReadWritePaths=, um bestimmte Pfade für den Schreibzugriff freizuschalten, falls ProtectSystem=strict verwandt wird. Beachten Sie, dass ReadWritePaths= nicht zum Erlangen von Schreibzugriff auf ein Dateisystem verwandt werden kann, dessen Superblock schreibgeschützt eingehängt ist. Unter Linux wird für jeden Einhängepunkt der Schreibzugriff nur erlaubt, falls der Einhängepunkt selbst und der ihm zugrundeliegende Dateisystemsuperblock nicht als schreibgeschützt markiert sind. ReadWritePaths= steuert nur ersteres und nicht letzteres, daher bleibt ein schreibgeschützter Dateisystemsuperblock geschützt.
In InaccessiblePaths= aufgeführte Pfade, einschließlich der Dateisystemhierarchie darunter, werden für Prozesse innerhalb des Namensraums unzugreifbar gemacht. Dies könnte restriktiver als gewünscht sein, da es nicht möglich ist, darin ReadWritePaths=, ReadOnlyPaths=, BindPaths= oder BindReadOnlyPaths= zu verschachteln. Für eine flexiblere Option siehe TemporaryFileSystem=.
Inhalte in den in NoExecPaths= aufgeführten Pfaden können nicht ausgeführt werden, selbst falls die gewöhnliche Zugriffskontrolle dies erlauben würde. Verschachteln Sie ExecPaths= innerhalb von NoExecPaths=, um ausführbaren Inhalt innerhalb nichtausführbarer Verzeichnisse bereitzustellen.
Es können auch Pfade, die keine Verzeichnisse sind, angegeben werden. Diese Optionen können mehr als einmal angegeben werden, dann haben alle aufgeführten Pfade von innerhalb des Namensraums aus beschränkten Zugriff. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste zurückgesetzt und alle vorherigen Zuweisungen haben keinen Effekt.
Pfaden in ReadWritePaths=, ReadOnlyPaths=, 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 Einhängungen von den Prozessen einer Unit zum Rechner abtrennt. Dies bedeutet, dass diese Einstellung nicht für Dienste benutzt werden darf, die in der Lage sein müssen, Einhängepunkte im Haupteinhängenamensraum zu installieren. Die ReadWritePaths=- und ReadOnlyPaths=-Ausbreitung in die andere Richtung ist nicht betroffen, d.h. Einhängungen, die im Rechner erstellt werden, tauchen im Allgemeinen im Namensraum der Unit auf und Einhängungen, die auf dem Rechner entfernt werden, verschwinden auch dort. Beachten Sie insbesondere, dass die Einhängeausbreitung vom Rechner zu der Unit dazu führt, dass unveränderte Einhängungen im Namensraum der Unit erstellt werden, d.h. schreibbare Einhängungen, die auf dem Rechner auftauchen, werden auch im Namensraum der Unit schreibbar sein, selbst wenn sie zu einem Pfad ausgebreitet werden, der mit ReadOnlyPaths= markiert ist! Daher wird die Zugriffseinschränkung mit diesen Optionen nicht auf Untereinhängungen eines Verzeichnisses, das später erstellt wird, ausgeweitet. Dies bedeutet, dass die durch diese Einstellung angebotene Sperrung nicht vollständig ist und keinen vollständigen Schutz bietet.
Beachten Sie, dass die Wirkung dieser Einstellung durch privilegierte Prozesse zurückgenommen werden kann. Um eine wirksame Sandbox-Umgebung für eine Unit einzurichten, wird daher empfohlen, diese Einstellungen mit entweder CapabilityBoundingSet=~CAP_SYS_ADMIN oder SystemCallFilter=~@mount zu kombinieren.
Seien Sie besonders vorsichtig, wenn Sie diese Optionen für API-Dateisysteme verwenden (eine Liste dieser können Sie unter MountAPIVPS= finden), da sie für grundlegende Systemfunktionalität notwendig sein können. Desweitern muss /run/ schreibbar sein, um Einhängenamensräume und Weiterleitung einzurichten.
Beispiel für 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 für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= implizit aktiviert (benötigt Unterstützung für nicht privilegierte Benutzernamensräume im Kernel mittels des Sysctl ».kernel.unprivileged_userns_clone=«).
Hinzugefügt in Version 231.
TemporaryFileSystem=
Akzeptiert eine Leerzeichen-getrennte Liste von Einhängepunkten für temporäre Dateisysteme (tmpfs). Falls gesetzt, wird ein neuer Dateisystemnamensraum für ausgeführte Prozesse eingerichtet und in jeden Einhängepunkt ein temporäres Dateisystem eingehängt. Diese Option kann mehr als einmal angegeben werden, dann werden an allen aufgeführten Einhängepunkten temporäre Dateisysteme eingehängt. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste zurückgesetzt und alle vorherigen Zuweisungen haben keinen Effekt. Jedem Einhängepunkt darf optional ein Doppelpunkt (»:«) und Einhängeoptionen wie »size=10%« oder »ro« angehängt werden. Standardmäßig wird jedes temporäre Dateisystem mit »nodev,strictatime,mode=0755« eingehängt. Dies kann durch explizite Angabe der entsprechenden Einhängeoptionen deaktiviert werden, z.B. »dev« oder »nostrictatime«.
Dies ist nützlich, um Dateien oder Verzeichnisse, die für die von der Unit gestarteten Prozesse nicht relevant sind, zu verstecken, während auf notwendige Dateien oder Verzeichnisse durch Kombination mit BindPaths= oder BindReadOnlyPaths= weiterhin zugegriffen werden kann:
Beispiel: Falls eine Unit die Einstellunng
TemporaryFileSystem=/var:ro
BindReadOnlyPaths=/var/lib/systemd
Der durch die Unit aufgerufene Prozess kann dann keine Dateien, Verzeichnisse oder Inhalte unter /var/ außer /var/lib/systemd sehen.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt in Version 238.
PrivateTmp=
Akzeptiert ein logisches Argument. Falls wahr, wird ein neuer Dateisystemnamensraum für den ausgeführten Prozess eingerichtet und private /tmp/- und /var/tmp/-Verzeichnisse darin eingehängt, die nicht mit Prozessen außerhalb des Namensraums gemeinsam genutzt werden. Dies ist nützlich, um Zugriff auf temporäre Dateien des Prozesses abzusichern, allerdings ist die gemeinsame Benutzung von Inhalten über /tmp/ oder /var/tmp/ mit anderen Prozessen unmöglich. Falls »wahr«, werden alle durch einen Dienst in diesen Verzeichnissen erstellten temporären Dateien entfernt, nachdem der Dienst gestoppt ist. Standardmäßig falsch. Es ist möglich, zwei oder mehr Units mit dem gleichen privaten /tmp/- und /var/tmp/-Namensraum durch Verwendung der Anweisung
JoinsNamespaceOf= zu benutzen, siehe
systemd.unit(5) für Details. Diese Einstellung ist impliziert, falls
DynamicUser= gesetzt ist. Für diese Einstellung gelten die gleichen Beschränkungen bezüglich Einhängeausbreitung und Privilegien wie für
ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Aktivieren dieser Einstellung hat den Seiteneffekt des Hinzufügens der Abhängigkeiten
Requires= und
After= zu allen für den Zugriff auf /tmp/ und /var/tmp/ notwendigen Einhänge-Units. Desweiteren wird eine implizite
After=-Ordnung auf
systemd-tmpfiles-setup.service(8) hinzugefügt.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Einhängenamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
PrivateDevices=
Akzeptiert ein logisches Argument. Falls wahr, wird eine neue /dev/-Einhängung für den ausgeführten Prozess eingerichtet und nur API-Pseudogeräte wie /dev/null, /dev/zero oder /dev/random (sowie das Pseudo-TTY-Untersystem) hinzugefügt, aber keine physischen Geräte wie /dev/sda, Systemspeicher /dev/mem, System-Ports /dev/port und andere. Dies ist nützlich, um Zugriff auf physische Geräte für ausgeführte Prozesse abzustellen. Standardmäßig falsch.
Aktivieren dieser Option wird einen Systemaufruffilter installieren, um systemnahe E/A-Systemaufrufe, die in der Gruppe @raw-io versammelt sind, zu blockieren, CAP_MKNOD und CAP_SYS_RAWIO aus der Capability-Begrenzungsmenge für die Unit zu entfernen und DevicePolicy=closed zu setzen (siehe systemd.resource-control(5) für Details). Beachten Sie, dass die Verwendung dieser Einstellung die Ausbreitung von Einhängungen aus dem Dienst zum Rechner trennen wird (Ausbreitung in die umgekehrte Richtung wird weiterhin funktionieren). Dies bedeutet, dass diese Einstellung nicht für Dienste benutzt werden kann, die in der Lage sein sollen, Einhängepunkte in dem Haupteinhängeraum zu installieren. Das neue /dev/ wird nur lesbar und »noexec« eingehängt. Letzteres könnte alte Programme beschädigen, die mit mmap(2) aus /dev/zero ausführbaren Speicher einrichten, statt MAP_ANON zu verwenden. Für diese Einstellung gelten die gleichen Einschränkungen im Hinblick auf Einhängeausbreitung und Privilegien wie für ReadOnlyPaths= und verwandte Aufrufe, siehe oben.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Einhängenamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Wenn Zugriff auf einige aber nicht alle Geräte möglich sein soll, kann stattdessen die Einstellung DeviceAllow= verwandt werden. Siehe systemd.resource-control(5).
Hinzugefügt in Version 209.
PrivateNetwork=
Akzeptiert ein logisches Argument. Falls wahr, wird ein Netzwerknamensraum für die ausgeführten Prozesse eingerichtet und darin nur das Loopback-Netzwerkgerät »lo« konfiguriert. Dem ausgeführten Prozess wird kein anderes Netzwerkgerät zur Verfügung stehen. Dies ist nützlich, um den ausgeführten Prozessen den Netzwerkzugriff zu verweigern. Standardmäßig falsch. Es ist möglich, zwei oder mehr Units mit dem gleichen privaten Netzwerknamensraum durch Verwendung der Anweisung
JoinsNamespaceOf= zu benutzen, siehe
systemd.unit(5) für Details. Beachten Sie, dass diese Option alle Socket-Einrichtungen, einschließlich
AF_NETLINK und
AF_UNIX, vom Rechner trennen wird. Effektiv bedeutet das für
AF_NETLINK, dass von
systemd-udevd.service(8) empfangene Gerätekonfigurationsereignisse nicht zu den Prozessen der Unit ausgeliefert werden. Und für
AF_UNIX hat dies den Effekt, dass
AF_UNIX-Sockets in dem abstrakten Namensraum des Rechners für Prozesse der Unit unverfügbar werden (allerdings werden solche im Dateisystem weiterhin zugreifbar sein).
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Netzwerknamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Wenn diese Option aktiviert ist, wird PrivateMounts= impliziert, außer es ist explizit deaktiviert und /sys wird neu eingehängt, 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 Netzwerknamensräumen von anderen Diensten auf Anfragen zu warten.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für 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-Einhängung oder einem Symlink darauf). Ist dies gesetzt, dann werden aufgerufene Prozesse zu dem durch diesen Pfad referenzierten Netzwerknamensraum hinzugefügt. Der Pfad muss zum Zeitpunkt des Aufrufs von »fork« auf eine gültige Netzwerknamensraumdatei zeigen. Falls diese Option verwandt wird, hat
PrivateNetwork= keine Wirkung. Falls diese Option zusammen mit
JoinsNamespaceOf= verwandt wird, dann hat sie nur eine Wirkung, falls diese Unit gestartet wird, bevor alle der aufgeführten Units, die
PrivateNetwork= oder
NetworkNamespacePath= konfiguriert haben, gestartet wird, da andernfalls der Netzwerknamensraum dieser Units neu verwendet wird.
Wenn diese Option aktiviert ist, wird PrivateMounts= impliziert, außer es ist explizit deaktiviert und /sys wird neu eingehängt, 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 für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt in Version 242.
PrivateIPC=
Akzeptiert ein logisches Argument. Falls wahr, wird ein neuer IPC-Namensraum für den ausgeführten 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 nützlich. Standardmäßig falsch. Es ist möglich, zwei oder mehr Units innerhalb des gleichen privaten IPC-Namensraum auszuführen, indem die Direktive
JoinsNamespaceOf= verwandt wird, siehe
systemd.unit(5) für Details.
Beachten Sie, dass IPC-Namensräume keinerlei Auswirkung auf AF_UNIX-Sockets haben, die die häufigste Form von IPC unter Linux sind. Stattdessen unterliegen AF_UNIX in dem Dateisystem den Einhängenamensräumen. IPC-Namensräume haben nur eine Auswirkung auf SysV-IPC (was größtenteils veraltet ist), sowie POSIX-Nachrichtenwarteschlangen (für die AF_UNIX-/SOCK_SEQPACKET-Sockets typischerweise die bessere Alternative sind). IPC-Namensräume haben auch keine Auswirkungen auf gemeinsam benutzten Speicher gemäß POSIX (der Einhängenamensräumen unterliegt). Siehe ipc_namespaces(7) für Details.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls IPC-Namensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt 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-Einhängung oder einem Symlink darauf). Ist dies gesetzt, dann werden aufgerufene Prozesse zu dem durch diesen Pfad referenzierten Netzwerknamensraum hinzugefügt. Der Pfad muss zum Zeitpunkt des Aufrufs von »fork« auf eine gültige Netzwerknamensraumdatei zeigen. Falls diese Option verwandt wird, hat
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 aufgeführten Units, die
PrivateIPC= oder
IPCNamespacePath= konfiguriert haben, gestartet wird, da andernfalls der Netzwerknamensraum dieser Units neu verwendet wird.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt in Version 248.
MemoryKSM=
Akzeptiert ein logisches Argument. Wenn gesetzt, aktiviert es KSM (Zusammenführung gleicher Seiten des Kernels) für den Prozess. KSM ist eine speichersparende Deduplizierungsfunktionalität. Anonyme Speicherseiten mit identischem Inhalt können durch eine einzelne, schreibgeschützte Seite ersetzt werden. Diese Funktionalität sollte nur für Aufträge aktiviert werden, die in der gleichen Sicherheitsdomäne sind. Zu Details siehe
Kernel Samepage Merging[7] in der Kerneldokumentation.
Beachten Sie, dass diese Funktionalität nicht verfügbar sein könnte, beispielsweise falls KSM im Kernel deaktiviert wurde oder der Kernel die Steuerung von KSM auf der Prozessebene mittels prctl(2)EN nicht unterstützt.
Hinzugefügt in Version 254.
PrivateUsers=
Akzeptiert ein logisches Argument. Falls wahr, richtet es einen neuen Benutzernamensraum für den ausgeführten Prozess ein und konfiguriert eine minimale Benutzer- und Gruppenabbildung, die den Benutzer und die Gruppe »root« sowie den Benutzer und die Gruppe der Unit auf sich selbst und alles andere auf den Benutzer und die Gruppe »nobody« abbildet. Dies ist nützlich, um die von der Unit verwandte Benutzer- und Gruppendatenbank sicher vom Rest des Systems abzutrennen und daher eine effektive Sandbox-Umgebung zu erstellen. Alle Dateien, Verzeichnisse, Prozesse, IPC-Objekte und andere Ressourcen, die nicht »root« (Benutzer/Gruppe) oder der Unit-eigenen gehören, bleiben von innerhalb der Unit sichtbar, scheinen aber dem Benutzer und der Gruppe »nobody« zu gehören. Falls dieser Modus aktiviert ist, werden alle Unit-Prozesse ohne Privilegien in dem Systembenutzernamensraum ausgeführt (unabhängig davon, ob der Benutzer / die Gruppe der Unit »root« ist oder nicht). Dies bedeutet insbesondere, dass der Prozess über keine Prozess-Capabilities im Systembenutzerraum, aber über volle Capabilities innerhalb des Benutzernamensraums des Dienstes verfügen wird. Einstellungen wie
CapabilityBoundingSet= beeinflussen nur Letzteren und es gibt keine Möglichkeit, zusätzliche Capabilities im Benutzerraum des Systems zu erlangen. Standardmäßig aus.
Wenn diese Einstellung durch eine benutzerbezogene Instanz des Diensteverwalters eingerichtet ist, entfällt die Abbildung des Benutzers und der Gruppe »root« auf sich selbst (außer der Benutzerverwalter ist root). Im Falle des benutzerbezogenen Instanzverwalters wird der Namensraum zusätzlich vor den meisten anderen Namensräumen eingerichtet. Das bedeutet, dass die Kombination von PrivateUsers=true mit anderen Namensräumen die Verwendung von Funktionalitäten aktiviert, die normalerweise von benutzerbezogenen Instanzen des Diensteverwalters nicht unterstützt werden.
Diese Einstellung ist insbesondere im Zusammenspiel mit RootDirectory=/RootImage= nützlich, da die Notwendigkeit, die Benutzer- und Gruppendatenbank im Wurzelverzeichnis und dem Gesamtsystem zu synchronisieren, reduziert wird, da die einzigen Benutzer und Gruppen, die angepasst werden müssen, »root«, »nobody« und der Benutzer und die Gruppe der Unit selbst sind.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Benutzernamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Hinzugefügt in Version 232.
ProtectHostname=
Akzeptiert ein logisches Argument. Wenn gesetzt, wird ein neuer UTS-Namensraum für den ausgeführten Prozess eingerichtet. Zusätzlich wird die Veränderung des »hostname« oder »domainname« verhindert. Standardmäßig »off«.
Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls UTS-Namensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt.
Beachten Sie, dass Änderungen des »hostname« sich nicht länger vom System in den Dienst ausbreiten, wenn diese Option für einen Dienst aktiviert ist. Daher ist sie nicht für Dienste geeignet, die dynamisch die Änderung des »hostname« des Systems beachten sollen.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt in Version 242.
ProtectClock=
Akzeptiert ein logisches Argument. Falls wahr, werden Schreibzugriffe auf die Hardware- oder System-Uhr verweigert. Standardmäßig aus. Aktivierung dieser Option entfernt
CAP_SYS_TIME und
CAP_WAKE_ALARM aus der Capability-Begrenzungsmenge für 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 berücksichtigt nicht, dass einige der Aufrufe zum Lesen des Uhrzustandes mit einigen Parameterkombinationen verwandt werden können. Effektiv werden dadurch /dev/rtc0, /dev/rtc1 usw. für den Dienst nur lesbar. Siehe
systemd.resource-control(5) für die Details von
DeviceAllow=.
Für die meisten Dienste, die die Uhr nicht verändern oder ihren Zustand prüfen müssen, wird empfohlen, dies einzuschalten.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt 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 verfügbaren Kernelvariablen für alle Prozesse der Unit nur lesbar. Normalerweise sollten einstellbare Kernelvariablen nur zum Systemstartzeitpunkt initialisiert werden, beispielsweise über den Mechanismus
sysctl.d(5). Zur Laufzeit müssen wenige Dienste diese schreiben, es wird daher empfohlen, dies für die meisten Dienste einzuschalten. Für diese Einstellung gelten die gleichen Einschränkungen bezüglich Einhängeausbreitung und Privilegien wie für
ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Standardmäßig aus. Beachten Sie, dass diese Option keine indirekten Änderungen an Kerneleinstellungen, die durch IPC-Aufrufe an andere Prozesse erfolgen, verhindert. Allerdings kann
InaccessiblePaths= verwandt werden, um die relevanten IPC-Dateisystemobjekte unzugreifbar zu machen. Falls
ProtectKernelTunables= gesetzt ist, wird
MountAPIVFS=yes impliziert.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt in Version 232.
ProtectKernelModules=
Akzeptiert ein logisches Argument. Falls wahr, wird das explizite Laden von Modulen verweigert. Dies erlaubt es, das Modulladen und -entladen für modulare Kernel abzuschalten. Es wird empfohlen, dieses für die meisten Dienste, die keine besonderen Dateisysteme oder zusätzliche Kernelmodule für ihre Arbeit benötigen, einzuschalten. Standardmäßig aus. Einschalten dieser Option entfernt
CAP_SYS_MODULE aus der Capability-Begrenzungsmenge für die Unit und installiert einen Systemaufruffilter, um Modulsystemaufrufe zu blockieren; sie macht auch /usr/lib/modules unzugreifbar. Für diese Einstellungen gelten die gleichen Einschränkungen bezüglich Einhängeausbreitung und Privilegien wie für
ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Beachten Sie, dass begrenztes automatisches Modulladen aufgrund von Benutzerkonfiguration oder Kernelabbildungstabellen als Seiteneffekt von angefragten Benutzeraktionen, sowohl privilegiert als auch unprivilegiert, weiterhin vorkommen kann. Um die Funktionalität des automatischen Modulladens zu deaktivieren, lesen Sie bitte die Dokumentation zum Mechanismus
kernel.modules_disabled von
sysctl.d(5) und /proc/sys/kernel/modules_disabled.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt in Version 232.
ProtectKernelLogs=
Akzeptiert ein logisches Argument. Falls wahr, wird der Zugriff auf den Kernelprotokollringpuffer verweigert. Für die meisten Dienste, die den Kernelprotokollringpuffer weder lesen noch schreiben müssen, wird empfohlen, dies einzuschalten. Aktivierung dieser Option entfernt
CAP_SYSLOG aus der Capability-Begrenzungsmenge für diese Unit und installiert einen Systemaufruffilter, um den Systemaufruf
syslog(2)EN (der nicht mit der Libc-API
syslog(3) für Benutzerprotokollierung durcheinandergebracht werden darf) blockiert. Der Kernel legt seinen Protokollpuffer mittels /dev/kmsg und /proc/kmsg offen. Falls aktiviert, werden diese für alle Prozesse der Unit nicht mehr zugreifbar sein.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt in Version 244.
ProtectControlGroups=
Akzeptiert ein logisches Argument. Falls wahr, werden die über /sys/fs/cgroup/ erreichbaren »Linux Control Groups« (
cgroups(7)EN)-Hierarchien für alle der Prozesse nur lesbar sein. Außer für Container-Verwalter sollte kein Dienst Schreibzugriff auf diese Control-Gruppenhierarchie benötigen; es wird daher empfohlen, dies für die meisten Dienste einzuschalten. Für diese Einstellungen gelten die gleichen Einschränkungen bezüglich Einhängeausbreitung und Privilegien wie für
ReadOnlyPaths= und verwandte Aufrufe, siehe oben. Standardmäßig aus. Falls
ProtectControlGroups= gesetzt ist, wird
MountAPIVFS=yes impliziert.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt in Version 232.
RestrictAddressFamilies=
Beschränkt die Gruppe der Socket-Adressfamilien, auf die Prozesse dieser Unit zugreifen können. 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) beschränkt. Sockets, die auf anderem Wege in die Unit hereingegeben werden (beispielsweise durch Verwendung von Socket-Aktivierung mit Socket-Units, siehe
systemd.socket(5)) sind davon nicht betroffen. Auch Sockets, die mit
socketpair() (was nur verbundene AF_UNIX-Sockets erstellt) erstellt werden, sind nicht betroffen. Beachten Sie, das diese Option keinen Effekt auf 32-Bit X86, S390, S390x, MIPS, MIPS-le, PPC, PPC-le, PPC64, PPC64-le hat und ignoriert wird (funktioniert aber auf anderen ABIs, einschließlich x86-64, korrekt). Beachten Sie, dass auf Systemen, die mehrere ABIs unterstützen (wie X86/X86-64), empfohlen wird, alternative ABIs für Dienste zu deaktivieren, so dass sie nicht zur Umgehung der Einschränkungen dieser Option verwandt werden können. Insbesondere wird empfohlen, diese Option mit
SystemCallArchitectures=native oder ähnlichem zu kombinieren. Standardmäßig werden keine Einschränkungen angewandt, Prozesse können auf alle Adressfamilien zugreifen. Falls die leere Zeichenkette zugewiesen wird, werden alle vorherigen Änderungen der Einschränkung der Adressfamilie zurückgenommen. Diese Einstellung betrifft keine Befehle, denen »+« vorangestellt sind.
Verwenden Sie diese Option, um den Kontakt des Prozesses für Zugriff aus der Ferne, insbesondere über exotische und heikle Netzwerkprotokolle wie AF_PACKET, zu begrenzen. Beachten Sie, dass in den meisten Fällen die lokale Adressfamilie AF_UNIX in die konfigurierte Freigabeliste aufgenommen werden sollte, da sie häufig für lokale Kommunikation verwandt wird, einschließlich für die syslog(2)EN-Protokollierung.
Hinzugefügt in Version 211.
RestrictFileSystems=
Beschränkt die Menge der Dateisysteme, auf denen Prozesse dieser Unit Dateien öffnen können. Akzeptiert eine Doppelpunkt-getrennte Liste von Dateisystemnamen. Alle aufgeführten Dateisysteme werden für die Prozesse der Unit zugreifbar gemacht, Zugriff auf nicht aufgeführte Dateisysteme wird verboten (Erlaubnisliste). Falls das erste Zeichen der Liste »-« ist, wird die Auswirkung invertiert: Zugriff auf die aufgeführten Dateisystem wird verboten (Ausschlussliste). Falls die leere Zeichenkette zugewiesen wird, wird der Zugriff auf Dateisysteme nicht beschränkt.
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 nächste Auftreten dieser Option die Liste der Dateisysteme zu der Menge der beschränkten Dateisysteme hinzufügen oder aus dieser löschen, abhängig 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 möglichen Dateisysteme groß 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 | Gebräuchliche Blockgeräte-Dateisysteme. |
| @historical-block | Historische Blockgeräte-Dateisysteme. |
| @network | Gut bekannte Netzwerk-Dateisysteme. |
| @privileged-api | Privilegierte Dateisystem API. |
| @temporary | Temporäre Dateisysteme: tmpfs, ramfs. |
| @known | Alle durch den Kernel definierten bekannten Dateisysteme. Diese Liste ist in Systemd statisch basierend auf der Kernelversion, die bei der Veröffentlichung von Systemd verfügbar 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 unterstützt werden könnte (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 Ausführungspfad in der Dienste-Unit umgangen werden, da sie für die gesamte Control-Gruppe gilt.
Hinzugefügt in Version 250.
RestrictNamespaces=
Begrenzt Zugriff auf die Linux-Namensraumfunktionalität für die Prozesse dieser Unit. Für Details über Linux-Namensräume siehe
namespaces(7). Akzeptiert entweder ein logisches Argument oder eine Leerraum-getrennte Liste von Namensraumtypkennzeichnern. Falls falsch (die Vorgabe), erfolgen keine Beschränkungen bezüglich Namensraumerstellung und -umschaltung. Andernfalls muss eine Leerzeichen-getrennte Liste von Namensraumtypkennzeichnern festgelegt werden, die aus einer Kombination von
cgroup,
ipc,
net,
mnt,
pid,
user und
uts bestehen. Jeder aufgeführte Namensraumtyp wird den Prozessen der Unit zugreifbar gemacht, Zugriff auf nicht aufgeführte Namensräume sind verboten (Freigabeliste). Durch Voranstellen des Tilde-Zeichens (»~«) kann der Effekt invertiert werden: nur die aufgeführten Namensraumtypen werden nicht zugreifbar gemacht, alle nicht aufgeführten sind erlaubt (Verbotsliste). Falls die leere Zeichenkette zugewiesen wird, werden die Vorgabe-Namensraumeinschränkungen angewandt, was zu falsch äquivalent ist. Diese Option kann mehr als einmal auftauchen. In diesem Fall werden die Namensraumtypen mit
ODER (oder mit
UND, falls den Zeilen »~« vorangestellt wird) zusammengefasst (siehe nachfolgende Beispiele). Intern begrenzt diese Einstellung Zugriff auf die Systemaufrufe
unshare(2)EN,
clone(2) und
setns(2)EN und berücksichtigt dabei die festgelegten Schalterparameter. Beachten Sie, dass bei Verwendung dieser Option zusätzlich zur Begrenzung der Erstellung und Umschaltung der festgelegten Namensraumtypen (oder allen von ihnen, falls wahr) Zugriff auf den Systemaufruf
setns() mit einem Nullschalterparameter verboten ist. Diese Einstellung wird nur auf X86, X86-64, MIPS, MIPS-le, MIPS64, MIPS64-le, MIPS64-n32, MIPS64-le-n32, PPC64, PPC64-le, S390 und S390x unterstützt und erwirkt auf anderen Architekturen keine Einschränkungen.
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.
Hinzugefügt in Version 233.
LockPersonality=
Akzeptiert ein logisches Argument. Falls gesetzt, sperrt es den Systemaufruf
personality(2), so dass die Kernel-Ausführungsdomäne nicht mehr von der Vorgabe oder von der mit der Anweisung
Personality= ausgewählten Personalität geändert werden kann. Dies kann zur Verbesserung der Sicherheit nützlich sein, da merkwürdige Personalitätsemulationen schlecht getestet und eine Quelle von Schwachstellen sein können.
Hinzugefügt in Version 235.
MemoryDenyWriteExecute=
Akzeptiert ein logisches Argument. Falls gesetzt, werden Versuche, Speicher-Mappings zu erstellen, die gleichzeitig schreib- und ausführbar sind oder bestehende Speicher-Mappings zu ändern, dass sie ausführbar werden oder gemeinsame Speichersegmente als ausführbar zu mappen, verboten. Insbesondere wird ein Systemaufruffilter hinzugefügt (oder, bevorzugt, wird eine äquivalente Kernelüberprüfung mittels
prctl(2)EN aktiviert), der
mmap(2)-Systemaufrufe mit sowohl gesetztem
PROT_EXEC als auch gesetztem
PROT_WRITE,
mprotect(2)EN- oder
pkey_mprotect(2)EN-Systemaufrufe mit gesetztem
PROT_EXEC und
shmat(2)-Systemaufrufe mit gesetztem
SHM_EXEC zurückgewiesen. Beachten Sie, dass diese Option mit Programmen und Bibliotheken, die Code dynamisch zur Laufzeit erstellen, inkompatibel ist. Zu dieser Gruppe gehören JIT-Ausführungsmaschinen, ausführbare Stacks und Code-»Trampolin«-Funktionalitäten verschiedener C-Compiler. Diese Option verbessert die Sicherheit, da es Software-Exploits erschwert, dynamisch laufenden Code zu ändern. Allerdings kann der Schutz umgangen werden, falls der Dienst in ein Dateisystem schreiben kann, das nicht mit der Option
noexec eingehängt ist (wie /dev/shm) oder er
memfd_create() verwenden kann. Dies kann verhindert werden, indem solche Dateisysteme für den Dienst unzugreifbar gemacht (z.B.
InaccessiblePaths=/dev/shm) und weitere Systemaufruffilter (
SystemCallFilter=~memfd_create) installiert werden. Beachten Sie, dass diese Funktionalität komplett auf X86-64 und teilweise auf X86 verfügbar ist. Insbesondere der
shmat()-Schutz ist auf X86 nicht verfügbar. Beachten Sie, dass auf Systemen, die mehrere ABIs unterstützen (wie X86/X84-64), es empfohlen wird, alternative ABIs für Dienste auszuschalten, so dass diese nicht zur Umgehung der Einschränkungen durch diese Option verwandt werden können. Insbesondere wird empfohlen, diese Option mit
SystemCallArchitectures=native oder ähnlichem zu kombinieren.
Hinzugefügt in Version 231.
RestrictRealtime=
Akzeptiert ein logisches Argument. Falls gesetzt, werden alle Versuche, Echtzeit-Scheduling für einen Prozess der Unit zu aktivieren, abgelehnt. Damit wird Zugriff auf die Echtzeitprogramm-Scheduling-Richtlinien wie
SCHED_FIFO,
SCHED_RR oder
SCHED_DEADLINE begrenzt. Siehe
sched(7)EN für Details über diese Scheduling-Richtlinien. Echtzeit-Scheduling-Richtlinien können zur Monopolisierung von CPU-Zeit für längere Zeitperioden verwandt werden und können daher dazu verwandt werden, das System zu sperren oder anderweitige Diensteverweigerungssituationen auf dem System auszulösen. Es wird daher empfohlen, den Zugriff auf Echtzeit-Scheduling auf die wenigen Programme, die dies tatsächlich benötigen, zu begrenzen. Standardmäßig aus.
Hinzugefügt 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 (für Details über diese Bits siehe
inode(7)EN). Da SUID/SGID ein Mechanismus zur Erhöhung der Rechte ist und Benutzern erlaubt, die Identität anderer Benutzer zu erlangen, wird empfohlen, die Erstellung von SUID/SGID-Dateien auf die wenigen Programme zu beschränken, die dies tatsächlich benötigen. Beachten Sie, dass dies die Markierung jeder Art von Dateisystemobjekt mit diesen Bits beschränkt, einschließlich regulärer Dateien und Verzeichnisse (auf denen das Bit SGID eine andere Bedeutung als bei Dateien hat, siehe Dokumentation). Diese Option ist impliziert, falls
DynamicUser= aktiviert ist. Standardmäßig »off«.
Hinzugefügt 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 läuft, gehören, entfernt, wenn die Unit gestoppt wird. Diese Einstellung hat nur einen Effekt, falls eines aus
User=,
Group= oder
DynamicUser= verwandt wird. Es hat keinen Effekt für IPC-Objekte, die dem Benutzer »root« gehören. Insbesondere entfernt dies System-V-Semaphoren sowie gemeinsam benutzte Segmente und Nachrichten-Warteschlangen gemäß System V und POSIX. Falls mehrere Units die gleichen Benutzer oder Gruppen verwenden, werden die IPC-Objekte entfernt, wenn die letzte dieser Units gestoppt wird. Diese Einstellung ist impliziert, falls
DynamicUser= gesetzt ist.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt in Version 232.
PrivateMounts=
Akzeptiert einen logischen Parameter. Falls gesetzt, wird diese Unit in ihrem eigenen privaten Dateisystem (Einhänge-)Namensraum betrieben, wobei alle Einhängeausbreitungen von dem Prozess in Richtung des Hauptdateisystems des Rechners abgeschaltet sind. Dies bedeutet, dass alle vom Prozess etablierten oder entfernten Dateisystemeinhängepunkte für diese privat und nicht im Hauptsystem sichtbar sind. Allerdings werden Dateisystemeinhängepunkte, die auf dem System etabliert oder entfernt werden, sich zu den Prozessen der Unit ausbreiten. Siehe
mount_namespaces(7) für Details bezüglich Dateisystemnamensräumen. Standardmäßig aus.
Falls eingeschaltet, wird dies drei Aktionen für jeden aufgerufenen Prozess auslösen: ein neuer CLONE_NEWNS-Namensraum wird erstellt, danach werden alle existierenden Einhängungen neu als MS_SLAVE eingehängt, um die Ausbreitung aus den Prozessen der Unit zu dem Hauptsystem zu deaktivieren (aber die Ausbreitung in die umgekehrte Richtung bleibt wirksam). Schließlich werden die Einhängungen erneut gemäß des in dem Schalter MountFlags= konfigurierten Ausbreitungsmodus eingehängt, siehe unten.
Dateisystemnamensräume werden individuell für jeden mit »fork« vom Diensteverwalter gestarteten Prozess eingerichtet. Einhängungen, die im Namensraum des durch ExecStartPre= erstellten Prozesses etabliert wurden, werden daher automatisch bereinigt, sobald der Prozess sich beendet und werden für nachfolgend durch ExecStart= mit Fork gestartete Prozesse nicht verfügbar sein (und Ähnliches gilt auch für die verschiedenen anderen für Units konfigurierten Befehle). Ähnlich erlaubt JoinsNamespaceOf= nicht die gemeinsame Benutzung von Kernelnamensräumen zwischen Units, es ermöglicht nur die gemeinsame Benutzung der Verzeichnisse /tmp/ und /var/tmp/.
Andere Dateisystemnamensräume-Einstellungen für Units — PrivateMounts=, PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=, ReadOnlyPaths=, InaccessiblePaths=, ReadWritePaths=, … — ermöglichen Dateisystemnamensräume in einer Art ähnlich dieser Option. Daher ist es primär zur expliziten Anfrage dieses Verhalten nützlich, falls keine der anderen Einstellungen verwandt wird.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
Hinzugefügt in Version 239.
MountFlags=
Akzeptiert eine Einhängeausbreitungseinstellung:
shared,
slave oder
private, die steuert, ob Dateisystemeinhängepunkte, die für die Prozesse dieser Unit in dem Dateisystemnamensraum eingerichtet wurden, Einhängungen oder Aushängungen aus anderen Dateisystemnamensräumen empfangen oder ausbreiten. Siehe
mount(2) für Details über Einhängeausbreitungen und insbesondere die drei Ausbreitungsschalter.
Diese Einstellung steuert nur die abschließenden Ausbreitungseinstellungen, die für alle Einhängepunkte des Dateisystemnamensraums, der für jeden Prozess dieser Unit erstellt wurde, wirksam sind. Andere Dateisystemnamensraum-Unit-Einstellungen (siehe die Diskussion in PrivateMounts= oben) werden implizit Einhänge- und Aushängeausbreitung von den Prozessen der Unit in Richtung des Systems deaktivieren, indem sie die Ausbreitungseinstellungen aller Einhängepunkte in dem Dateisystemnamensraum der Unit zuerst auf slave setzen. Setzen der Option auf shared richtet die Ausbreitung in diesem Fall nicht wieder ein.
Falls nicht gesetzt – aber es sind durch andere Dateisystemnamensraumeinstellungen der Unit keine Dateisystemnamensräume aktiviert –, wird shared Einhängeausbreitung verwandt, aber wie erwähnt, wird slave zuerst angewandt, Ausbreitung von den Prozessen der Unit zum Hauptsystem bleibt weiterhin abgeschaltet.
Es wird nicht empfohlen, private Einhängeausbreitung für Units zu verwenden, da dies bedeutet, dass temporäre Einhängungen (wie Wechselmedien) auf dem Hauptsystem eingehängt bleiben und daher unbefristet in mit Fork erstellten Programmen als beschäftigt markiert sind, da die Aushängeausbreitungsereignisse in dem Dateisystemnamensraum der Unit nicht empfangen werden.
Normalerweise ist es am besten, diese Einstellung unverändert zu lassen und stattdessen abstraktere Dateisystemnamensraumoptionen zu verwenden, insbesondere PrivateMounts=, siehe oben.
Diese Option ist nur für Systemdienste verfügbar oder für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen. In diesem Fall ist PrivateUsers= impliziert aktiviert (benötigt im Kernel mittels des Sysctl »kernel.unprivileged_userns_clone=« aktivierte Unterstützung für nicht privilegierten Benutzernamensraum).
StandardInput=
Steuert, womit der Dateideskriptor 0 (STDIN) des ausgeführten Prozesses verbunden ist. Akzeptiert
null,
tty,
tty-force,
tty-fail,
data,
file:Pfad,
socket oder
fd:Name.
Falls null ausgewählt wird, wird die Standardeingabe mit /dev/null verbunden, d.h. alle Leseversuche durch den Prozess werden sofort zu einem EOF führen.
Falls tty ausgewählt ist, wird die Standardeingabe mit einem TTY (wie mit TTYPath= konfiguriert, siehe unten) verbunden und der ausgeführte Prozess wird der steuernde Prozess des Terminals. Falls das Terminal bereits durch einen anderen Prozess gesteuert wird, wartet der ausgeführte Prozess, bis der derzeit steuernde Prozess das Terminal freigibt.
tty-force ist ähnlich zu tty, der ausgeführte Prozess wird aber zwangsweise und sofort zum steuernden Prozess des Terminals gemacht, möglicherweise werden dabei vorhergehende steuernde Prozesse von dem Terminal entfernt.
tty-fail ist ähnlich zu tty, falls aber das Terminal bereits einen steuernden Prozess hat, schlägt das Hochfahren des ausgeführten Prozesses fehl.
Die Option data kann zur Konfiguration beliebiger textueller oder binärer Daten, die mittels Standardeingabe an den ausgeführten Prozess übergeben werden sollen, verwandt werden. Die zu übergebenden Daten werden mittels StandardInputText=/StandardInputData= (siehe unten) konfiguriert. Beachten Sie, dass der tatsächlich übergebene Dateideskriptortyp (Speicherdatei, reguläre Datei, UNIX-Pipe, …) vom Kernel und den verfügbaren Privilegien abhängen könnte. Auf jeden Fall ist der Dateideskriptor nur lesbar und er liefert die festgelegten Daten, gefolgt von EOF, zurück, wenn er gelesen wird.
Die Option file:Pfad kann zur Verbindung der Standardeingabe mit einem bestimmten Dateisystemobjekt verwandt werden. Es wird ein absoluter Pfad gefolgt von dem Zeichen »:« erwartet, der sich auf eine reguläre Datei, ein FIFO oder eine Spezialdatei beziehen kann. Falls ein AF_UNIX-Socket in dem Dateisystem festgelegt ist, wird mit ihm ein Datenstrom-Socket verbunden. Letzteres ist nützlich, um die Standardeingabe eines beliebigen Prozesses mit einem beliebigen Systemdienst zu verbinden.
Die Option »socket« ist nur in Socket-aktivierten Diensten gültig und es muss in der relevanten Socket-Unit-Datei (siehe systemd.socket(5) für Details) Accept=yes gesetzt oder nur ein einzelnes Socket spezifiziert sein. Falls diese Option gesetzt ist, wird die Standardeingabe mit dem Socket, aus dem der Dienst aktiviert wurde, verbunden. Dies ist hauptsächlich für die Kompatibilität mit Daemons nützlich, die für die Verwendung mit der traditionellen inetd(8)-Socket-Daemon-Aktivierung entwickelt wurden (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 äquivalent zu »fd:stdin«). Mindestens eine Socket-Unit, die den angegebenen Namen definiert, muss über die Option Sockets= bereitgestellt werden und der Dateideskriptorname darf sich vom Namen der Socket-Unit, die ihn enthält, unterscheiden. Falls mehrere Treffer gefunden werden, wird der erste verwandt. Siehe FileDescriptorName= in systemd.socket(5) für weitere Details über benannte Dateideskriptoren und ihrer Sortierung.
Diese Einstellung ist standardmäßig null, außer StandardInputText=/StandardInputData= sind gesetzt, dann ist die Vorgabe data.
StandardOutput=
Steuert, womit der Dateideskriptor 1 (Stdout) des ausgeführten Prozesses verbunden ist. Akzeptiert entweder
inherit,
null,
tty,
journal,
kmsg,
journal+console,
kmsg+console,
file:Pfad,
append:Pfad,
truncate:Pfad,
socket oder
fd:Name.
inherit dupliziert den Dateideskriptor der Standardeingabe für die Standardausgabe.
null verbindet die Standardausgabe mit /dev/null, d.h. alles dahin Geschriebene geht verloren.
tty verbindet die Standardausgabe mit einem TTY (wie in TTYPath= konfiguriert, siehe unten). Falls das TTY nur für die Ausgabe verwandt wird, wird der ausgeführte Prozess nicht der steuernde Prozess des Terminals werden und wird nicht fehlschlagen oder darauf warten, dass andere Prozesse das Terminal freigeben.
journal verbindet die Standardausgabe mit dem Journal, das über journalctl(1) erreichbar ist. Beachten Sie, dass alles, was nach Syslog oder Kmsg (siehe unten) geschrieben wird, implizit auch im Journal gespeichert wird, die spezielle unten aufgeführten Optionen ist daher eine Obermenge dieser Option. (Beachten Sie auch, dass alle externen, zusätzlichen Syslog-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 über dmesg(1) erreichbar ist, zusätzlich zum Journal. Der Journal-Daemon könnte so konfiguriert sein, dass er alles, was er empfängt, sowieso zu Kmsg sendet, wodurch diese Option in diesem Fall keinen Unterschied zu journal darstellt.
journal+console und kmsg+console arbeiten auf eine ähnliche Art wie die zwei Optionen oben, kopieren aber auch sämtliche Ausgabe auf die Systemkonsole.
Die Option file:Pfad kann zum Verbinden eines bestimmten Dateisystemobjektes mit der Standardausgabe verwandt werden. Die Semantik ist ähnlich zu der der gleichen Option von StandardInput=, siehe oben. Falls sich Pfad auf eine reguläre Datei auf dem Dateisystem bezieht, wird sie zum Schreiben am Anfang der Datei geöffnet (erstellt, falls sie noch nicht existiert), aber ohne sie abzuschneiden. Falls die Standardeingabe und -ausgabe auf den gleichen Dateipfad verwiesen werden, wird dieser nur einmal – zum Lesen und Schreiben – geöffnet und dupliziert. Dies ist insbesondere nützlich, wenn sich der festgelegte Pfad auf ein AF_UNIX-Socket im Dateisystem bezieht, da in diesem Fall nur eine einzelne Datenstromverbindung für sowohl Ein- als auch Ausgabe erstellt wird.
append:Pfad ist ähnlich zu file:Pfad oben, es öffnet die Datei aber im Anhängemodus.
truncate:Pfad ist ähnlich zu obigem file:Pfad, schneidet die Datei beim Öffnen aber ab. Für Units mit mehreren Befehlszeilen, z.B. Type=oneshot-Dienste mit mehreren ExecStart= oder Diensten mit ExecCondition=, ExecStartPre= oder ExecStartPost=, wird die Ausgabedatei erneut für jede Befehlszeile geöffnet und daher erneut abgeschnitten. Falls die Ausgabedatei abgeschnitten wird, während ein anderer Prozess die Datei noch geöffnet hat, z.B. durch ein ExecReload=, das parallel zu einem ExecStart= ausgeführt 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) aufgefüllt werden, wodurch eine Sparse-Datei erzeugt wird. Daher ist truncate:Pfad normalerweise nur mit einer einzelnen ExecStart= und keinem ExecStartPost=, ExecReload=, ExecStop= oder ähnlichem nützlich.
socket verbindet die Standardausgabe zu einem mittels Socket-Aktivierung erlangten Socket. Die Semantik ist ähnlich zu der der gleichen Option von StandardInput=, siehe oben.
Die Option fd:Name verbindet die Standardausgabe mit einem bestimmten benannten, durch eine Socket-Unit bereitgestellten Dateideskriptor. Es kann als Teil dieser Option ein Name, gefolgt von einem »:«-Zeichen, angegeben werden (z.B. »fd:foobar«). Falls kein Name angegeben ist, wird der Name »stdout« impliziert (d.h. »fd« ist äquivalent zu »fd:stdout«). Mindestens eine Socket-Unit, die den angegebenen Namen definiert, muss über die Option Sockets= bereitgestellt werden und der Dateideskriptorname darf sich vom Namen der Socket-Unit, die ihn enthält, unterscheiden. Falls mehrere Treffer gefunden werden, wird der erste verwandt. Siehe FileDescriptorName= in systemd.socket(5) für weitere Details über benannte Dateideskriptoren und ihrer Sortierung.
Falls die Standardausgabe (oder die Fehlerausgabe, siehe unten) einer Unit mit dem Journal oder dem Kernelprotokollpuffer verbunden ist, wird die Unit implizit eine Abhängigkeit vom Typ After= von systemd-journald.socket erhalten (siehe auch den Abschnitt »Implizite Abhängigkeiten« oben). Beachten Sie auch, dass in diesem Fall Stdout (oder Stderr, siehe unten) ein AF_UNIX-Datenstrom-Socket und keine PIPE oder FIFO, die erneut geöffnet werden kann, sein wird. Das bedeutet, dass bei der Ausführung von Shell-Skripten die Konstruktion »echo "hello" > /dev/stderr« zum Schreiben von Text nach Stderr nicht funktionieren wird. Um dies zu entschärfen, verwenden Sie stattdessen die Konstruktion »echo "hello" >&2«, die größtenteils äquivalent ist und diesen Fallstrick vermeidet.
Falls StandardInput= auf entweder tty, tty-force, tty-fail, socket oder fd:Name gesetzt ist, die die Vorgabe für diese Einstellung inherit.
In anderen Fällen ist der Vorgabewert dieser Einstellung der mit DefaultStandardOutput= in systemd-system.conf(5) gesetzte Wert, der standardmäßig journal ist. Beachten Sie, dass dieser Parameter zum Hinzufügen zusätzlicher Abhängigkeiten führen kann (siehe oben).
StandardError=
Steuert, womit Dateideskriptor 2 (Stderr) des ausgeführten Prozesses verbunden ist. Die verfügbaren Optionen sind identisch zu denen von
StandardOutput= mit einigen Ausnahmen: falls auf
inherit gesetzt, wird der für die Standardausgabe verwandte Dateideskriptor für die Standardfehlerausgabe dupliziert, während
fd:Name den vorgegebenen Dateideskriptornamen von »stderr« verwenden wird.
Der Vorgabewert dieser Einstellung ist der mit DefaultStandardError= in systemd-system.conf(5) gesetzte Wert, der standardmäßig inherit ist. Beachten Sie, dass dieser Parameter zum Hinzufügen zusätzlicher Abhängigkeiten führen kann (siehe oben).
StandardInputText=, StandardInputData=
Konfiguriert beliebige textuelle oder binäre Daten, die mittels Dateideskriptor 0 (STDIN) an den ausgeführten Prozess übergeben werden sollen. Diese Einstellung hat keine Wirkung, außer
StandardInput= ist auf
data gesetzt (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 für besondere Zeichen sowie die normalen »%«-Kennzeichner werden aufgelöst. Jedes Mal, wenn diese Einstellung benutzt wird, wird der festgelegte Text an den Unit-bezogenen Datenpuffer, gefolgt von einem Zeilenumbruchzeichen, angehängt (daher hängt jeder Einsatz eine neue Zeile an das Ende des Puffers an). Beachten Sie, dass einleitende und abschließende Leerraumzeichen von mit dieser Option konfigurierten Zeilen entfernt werden. Falls eine leere Zeile festgelegt wird, wird der Puffer bereinigt (daher sollte ein zusätzliches »\n« an das Ende oder den Anfang einer Zeile eingefügt werden, um eine leere Zeile einzufügen).
StandardInputData= akzeptiert beliebige, in Base64[14] kodierte binäre Daten. Es werden keine Maskiersequenzen oder Kennzeichner aufgelöst. Sämtliche Leerraumzeichen in der kodierten Version werden während der Dekodierung ignoriert.
Beachten Sie, dass StandardInputText= und StandardInputData= auf dem gleichen Datenpuffer arbeiten und gemischt werden können, um sowohl binäre als auch textuelle Daten für den gleichen Eingabedatenstrom zu konfigurieren. Die textuellen oder binären Daten werden genau in der Reihenfolge zusammengefügt, in der sie in der Unit-Datei auftauchen. Wird einem eine leere Zeichenkette zugewiesen, wird der Datenpuffer zurückgesetzt.
Bitte beachten Sie, dass lange Unit-Dateieinstellungen in mehrere Zeilen aufgeteilt werden können, um die Lesbarkeit zu erhalten. Hierzu wird jeder Zeile (außer der letzten) ein Zeichen »\« vorangestellt (siehe systemd.unit(5) für Details). Dies ist insbesondere für große Daten, die mit diesen Optionen konfiguriert werden, nützlich. Beispiel:
…
StandardInput=data
StandardInputData=V2XigLJyZSBubyBzdHJhbmdlcnMgdG8gbG92ZQpZb3Uga25vdyB0aGUgcnVsZXMgYW5kIHNvIGRv \
IEkKQSBmdWxsIGNvbW1pdG1lbnQncyB3aGF0IEnigLJtIHRoaW5raW5nIG9mCllvdSB3b3VsZG4n \
dCBnZXQgdGhpcyBmcm9tIGFueSBvdGhlciBndXkKSSBqdXN0IHdhbm5hIHRlbGwgeW91IGhvdyBJ \
J20gZmVlbGluZwpHb3R0YSBtYWtlIHlvdSB1bmRlcnN0YW5kCgpOZXZlciBnb25uYSBnaXZlIHlv \
dSB1cApOZXZlciBnb25uYSBsZXQgeW91IGRvd24KTmV2ZXIgZ29ubmEgcnVuIGFyb3VuZCBhbmQg \
ZGVzZXJ0IHlvdQpOZXZlciBnb25uYSBtYWtlIHlvdSBjcnkKTmV2ZXIgZ29ubmEgc2F5IGdvb2Ri \
eWUKTmV2ZXIgZ29ubmEgdGVsbCBhIGxpZSBhbmQgaHVydCB5b3UK
… Hinzugefügt in Version 236.
LogLevelMax=
Konfiguriert eine Filterung gemäß Protokollierstufe der durch diese Unit erstellten Protokollnachrichten. Akzeptiert eine
syslog-Protokollstufe, entweder
emerg (niedrigste Protokollierstufe, nur Nachrichten höchster Priorität),
alert,
crit,
err,
warning,
notice,
info oder
debug (höchste Protokollierstufe, auch Nachrichten niedrigster Priorität). Siehe
syslog(3) für Details. Standardmäßig wird keine Filterung angewandt (d.h. die maximale Protokollierstufe ist standardmäßig
debug). Verwenden Sie diese Option, um das Protokolliersystem zu konfigurieren, damit es Protokollnachrichten eines bestimmten Dienstes oberhalb der festgelegten Stufe verwirft. Setzen Sie beispielsweise
LogLevelMax=info, um die Fehlersuchprotokollierung eines bestimmten, gesprächigen Dienstes auszuschalten. Beachten Sie, dass die konfigurierte Stufe auf alle versandten Protokollnachrichten aller zu diesem Dienst gehörenden Prozesse sowie allen vom Systemverwalterprozess (PID 1) geschriebenen Protokollnachrichten mit Referenz auf diese Unit auf allen unterstützten Protokollierungsprotokollen angewandt wird. Die Filterung erfolgt frühzeitig in der Protokollierungspipeline, bevor jegliche Art weiterer Verarbeitung erfolgt. Desweiteren könnten Nachrichten, die erfolgreich durch diesen Filter kommen, dennoch durch angewandte Filter in einer späteren Stufe im Protokollierungsuntersystem verworfen werden. Beispielsweise könnte ein in
journald.conf(5) konfiguriertes
MaxLevelStore= verbieten, Nachrichten von höheren Protokollierstufen auf Platte zu speichen, selbst wenn das Unit-bezogene
LogLevelMax= die Verarbeitung erlaubte.
Hinzugefügt in Version 236.
LogExtraFields=
Konfiguriert zusätzliche Protokollmetadatenfelder, die in alle Protokolldatensätze aufgenommen werden, die von Prozessen, die dieser Unit zugeordnet sind (einschließlich Systemd), erstellt werden. Diese Einstellung akzeptiert eine oder mehrere Journal-Feldzuweisungen im Format »FELD=WERT«, getrennt durch Leerraumzeichen. Siehe
systemd.journal-fields(7) für Details zum Journal-Feldkonzept. Obwohl die zugrundeliegende Journal-Implementierung binäre Feldnamen erlaubt, akzeptiert diese Einstellung nur gültige UTF-8-Werte. Um Leerzeichen in einem Journal-Feldwert aufzunehmen, schließen Sie die Zuweisung in doppelte Anführungszeichen (") ein. Die normalen Kennzeichner werden in allen Zuweisungen expandiert (siehe unten). Beachten Sie, dass diese Einstellung nicht nur für das Anhängen von zusätzlichen Metadaten an Protokolldatensätzen einer Unit nützlich ist. Da alle Felder und Werte indiziert sind, kann dies auch für Unit-übergreifenden Protokolldatensatzabgleich verwandt werden. Wird eine leere Zeichenkette zugewiesen, wird die Liste zurückgesetzt.
Hinzugefügt 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 vorüber ist. Es wird eine Meldung über die verworfenen Nachrichten erstellt. Die Zeitspezifikation für
LogRateLimitIntervalSec= kann in einer der folgenden Einheiten erfolgen: »s«, »min«, »h«, »ms«, »us«. Siehe
systemd.time(7) für Details. Die Voreinstellungen erfolgen durch die in
journald.conf(5) konfigurierten
RateLimitIntervalSec= und
RateLimitBurst=. 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 über
StandardOutput=file:… oder einer ähnlichen Einstellung direkt mit einer Datei verbinden (aber sie wird für mittels
syslog(3) oder ähnlichen Funktionen erstellten Meldungen durchgesetzt).
Hinzugefügt in Version 240.
LogFilterPatterns=
Definiert einen erweiterten regulären 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 zurückgesetzt 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 würde »~foobar« ein Muster hinzufügen, das »foobar« zu der Verbotsliste hinzufügt, während »\x7efoobar« ein Muster, das auf »~foobar« passt, zu der Erlaubt-Liste hinzufügt.
Protokollmeldungen werden gegen Verbotsmuster geprüft (falls vorhanden), dann gegen Erlaubt-Muster (falls vorhanden). Falls eine Protokollmeldung auf eines der Verbotsmuster passst, wird sie verworfen, unabhängig von den Erlaubt-Mustern. Dann werden die verbliebenen Protokollmeldungen gegen die Erlaubt-Muster geprüft. 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, für die LogFilterPatterns= definiert ist. Das bedeutet, dass von systemd(1) stammende Protokollmeldungen über die Unit nicht berücksichtigt 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.
Hinzugefügt in Version 253.
LogNamespace=
Führt 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 ausgeführt, d.h. ihr Protokolldatenstrom wird durch systemd-journald.service gesammelt und verarbeitet. Falls diese Option verwandt wird, werden sämtliche von Prozessen dieser Unit erstellte Protokolldaten (unabhängig, 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 unabhängig vom Datenspeicher des Vorgabe-Protokoll-Namensraums ist. Siehe
systemd-journald.service(8) für Details über Journal-Namensräume.
Intern sind Journal-Namensräume mittes Linux-Einhängenamensräume und durch Übereinhängen des Verzeichnisses, das die relevanten AF_UNIX-Sockets für das Protokollieren in dem Einhängenamensraum enthält, implementiert. Da Einhängenamensräume verwandt werden, trennt diese Einstellung die Weiterleitung von Einhängungen von den Prozessen der Unit zu dem Rechner ab, ähnlich wie ReadOnlyPaths= und ähnliche oben beschriebene Einstellungen funktionieren. Journal-Namensräume können daher nicht für Dienste verwandt werden, die Einhängepunkte auf dem Rechner etablieren müssen.
Wenn diese Option gesetzt ist, wird die Unit automatisch Ordnungs- und Anforderungsabhängigkeiten 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 regulären journalctl(1)-Ausgabe erscheint, außer die Option --namespace= wird verwandt.
Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt.
Hinzugefügt 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 ausgeführten Prozesses. Diese Option ist nur nützlich, wenn StandardOutput= oder StandardError= auf journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit +console). Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden, angewandt.
SyslogFacility=
Setzt den
syslog-Einrichtungskennzeichner, der beim Protokollieren verwandt werden soll. Entweder
kern,
user,
mail,
daemon,
auth,
syslog,
lpr,
news,
uucp,
cron,
authpriv,
ftp,
local0,
local1,
local2,
local3,
local4,
local5,
local6 oder
local7. Siehe
syslog(3) für Details. Diese Option ist nur nützlich, wenn
StandardOutput= oder
StandardError= auf
journal oder
kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit
+console). Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden, angewandt. Standardmäßig
daemon.
SyslogLevel=
Die Vorgabe-
syslog-Protokollierstufe, die beim Protokollieren zum Protokollierungssystem oder Kernelprotokollpuffer verwandt werden soll. Entweder
emerg,
alert,
crit,
err,
warning,
notice,
info oder
debug. Siehe
syslog(3) für Details. Diese Option ist nur nützlich, wenn
StandardOutput= oder
StandardError= auf
journal oder
kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit
+console). Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden, angewandt. Beachten Sie, dass individuellen Zeilen, die von ausgeführten Prozessen ausgegeben werden, eine andere Protokollierungsstufe vorangestellt werden kann, die dazu verwandt werden kann, die hier festgelegte Vorgabeprotokollstufe außer Kraft zu setzen. Die Auswertung dieser vorangestellten Werte kann mit
SyslogLevelPrefix= deaktiviert werden, siehe unten. Für Details siehe
sd-daemon(3). Standardmäßig
info.
SyslogLevelPrefix=
Akzeptiert ein logisches Argument. Falls wahr und StandardOutput= oder StandardError= auf journal oder kmsg gesetzt ist (oder die gleichen Einstellungen in Kombination mit +console), wird Protokollzeilen, die durch die ausgeführten Prozesse geschrieben werden, denen eine Protokollierungsstufe vorangestellt ist, verarbeitet, wobei die vorangestellte Protokollierungsstufe entfernt wird. Falls auf falsch gesetzt, wird die Auswertung dieser vorangestellten Werte deaktiviert und die protokollierten Zeilen unverändert weitergegeben. Dies gilt nur für Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden. Für Details bezüglich des Voranstellens siehe sd-daemon(3). Standardmäßig wahr.
TTYPath=
Setzt den zu verwendenden Terminalgeräteknoten, falls die Standardeingabe, -ausgabe oder -fehlerausgabe mit einem TTY verbunden ist (siehe oben). Standardmäßig /dev/console.
TTYReset=
Setzt das mit TTYPath= festgelegte Terminalgerät vor und nach der Ausführung zurück. Standardmäßig »no«.
TTYVHangup=
Trennt alle Clients, die das mit TTYPath= festgelegte Terminalgerät vor und nach der Ausführung geöffnet haben. Standardmäßig »no«.
TTYRows=, TTYColumns=
Konfiguriert die Größe des mit
TTYPath= festgelegten TTYs. Falls nicht oder auf die leere Zeichenkette gesetzt, wird die Vorgabe des Kernels verwandt.
Hinzugefügt in Version 250.
TTYVTDisallocate=
Falls das mit TTYPath= festgelegte Terminalgerät ein virtuelles Konsolenterminal ist, wird vor und nach der Ausführung versucht, die Zuordnung aufzuheben. Dies sorgt dafür, dass der Bildschirm und der Scrollback-Puffer (Puffer mit vorherigen Ein-/Ausgaben) gelöscht werden. Standardmäßig »no«.