Die Einstellungen MountAPIVFS= und PrivateUsers= sind inbesondere in Zusammenhang mit RootDirectory= nützlich. Für Details siehe unten.

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.

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 Einschränkungen bei der Namenssyntax der Benutzer/Gruppen erzwungen werden: der festgelegte Name darf nur aus den Zeichen a-z, A-Z, 0-9, »_« und »-« (außer beim ersten Zeichen, das eines aus a-z, A-Z oder »_« sein muss, d.h. Zahlen und »-« sind nicht als erstes Zeichen erlaubt) bestehen. Der Benutzer-/Gruppenname muss mindestens ein und maximal 31 Zeichen enthalten. Diese Einschränkungen werden erzwungen, um Mehrdeutigkeiten zu vermeiden und um sicherzustellen, dass Benutzer-/Gruppennamen und Unit-Dateien zwischen Linux-Systemen portierbar bleiben.

Wenn dies zusammen mit DynamicUser= verwandt wird, wird der festgelegte Benutzer-/Gruppename dynamisch zum Startzeitpunkt des Dienstes zugewiesen und beim Beenden des Dienstes wieder freigegeben — außer er ist bereits statisch zugewiesen (siehe unten). Falls DynamicUser= nicht verwandt wird, muss der festgelegte Benutzer und die festgelegte Gruppe spätestens beim Startmoment des Dienstes statisch in der Benutzerdatenbank erzeugt worden sein, beispielsweise mit der Einrichtung sysusers.d(5), die beim Systemstart oder zum Zeitpunkt der Paketinstallation angewandt wird.

Beachten Sie, dass für jede Unit, die diese Option einsetzt, ein PAM-Sitzungshandhabungsprozess als Teil der Unit verwaltet und aktiv gehalten wird, solange die Unit aktiv ist, um sicherzustellen, dass geeignete Aktionen unternommen werden können, wenn die Unit und damit die PAM-Sitzung beendet wird. Dieser Prozess heißt »(sd-pam)« und ist ein direkter Kindprozess des Hauptprozesses der Unit.

Beachten Sie, dass es sehr wahrscheinlich ist (abhängig von der PAM-Konfiguration), dass der Haupt-Unit-Prozess in seine eigene Sitzungsgeltungsbereich-Unit migriert wird, wenn diese Option für eine Unit verwandt und sie aktiviert wird. Dieser Prozess wird daher zwei Units zugeordnet sein: der Unit, in der er ursprünglich gestartet wurde (und für die PAMName= konfiguriert wurde) und der Sitzungsgeltungsbereichs-Unit. Jeder Kindprozess dieses Prozesses wird allerdings nur der Sitzungsgeltungsbereichs-Unit zugeordnet sein. Dies hat Auswirkungen, wenn das in Kombination mit NotifyAccess=all verwandt wird, da diese Kindprozesse nicht in der Lage sein werden, Änderungen an der usprünglichen Unit über Benachrichtigungsmeldungen zu erreichen. Es wird angenommen, dass diese Nachrichten zu der Sitzungsgeltungsbereichs-Unit und nicht der ursprünglichen Unit gehören. Es wird daher nicht empfohlen, PAMName= in Kombination mit NotifyAccess=all zu verwenden.

Beispiel: Falls eine Unit die Einstellunng

CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=CAP_B CAP_C

hat, dann werden CAP_A, CAP_B und CAP_C gesetzt. Falls der zweiten Zeile »~« vorangestellt wird, d.h.

CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=~CAP_B CAP_C

dann wird nur CAP_A gesetzt.

Umgebungs-Capabilitymengen sind nützlich, falls Sie einen Prozess als nicht privilegierten Benutzer ausführen wollen, ihm aber dennoch einige Capabilities geben möchten. Beachten Sie, dass in diesem Fall die Option keep-caps automatisch zu SecureBits= hinzugefügt ist, um die Capabilities über den Benutzerwechsel hinweg zu erhalten. AmbientCapabilities= betrifft keine Befehle, denen »+« vorangestellt ist.

Diesem Wert kann »-« vorangestellt werden, wodurch alle Fehler ignoriert werden. Ein leerer Wert kann festgelegt werden, um alle vorhergehenden Zuweisungen zurückzusetzen. Dies betrifft nicht Befehle, denen »+« vorangestellt ist.

Beachten Sie, dass die meisten der mit diesen Optionen konfigurierten Ressourcenbeschränkungen prozessbezogen sind und dass Prozesse einen Fork durchführen können, um einen neuen Satz an Ressourcen zu erlangen, die unabhängig vom ursprünglichen Prozess verbucht werden und daher gesetzten Beschränkungen entkommen können. Beachten Sie auch, dass LimitRSS= unter Linux nicht implementiert ist und das Setzen keinen Effekt hat. Oft ist es ratsam, die in systemd.resource-control(5) aufgeführten Ressourcensteuerungen gegenüber den prozessabhängigen zu bevorzugen, da sie auf Dienste als ganzes angewandt, zur Laufzeit verändert werden und im Allgemeinen ausdrucksstärker sind. Beispielsweise ist MemoryLimit= ein leistungsfähigerer (und funktionierender) Ersatz für LimitRSS=.

Für System-Units können diese Ressourcenbeschränkungen frei ausgewählt werden. Für Benutzer-Units (d.h. Units, die als benutzerbezogene Instanz von systemd(1) ausgeführt werden) wird allerdings eine Begrenzungen durch (möglicherweise weiter eingeschränkte) benutzerbezogene Einschränkungen durch das Betriebssystem erzwungen.

Nicht explizit konfigurierte Ressourcenbeschränkungen für eine Unit verwenden als Vorgabe die in den verschiedenen in systemd-system.conf(5) verfügbare Optionen DefaultLimitCPU=, DefaultLimitFSIZE=, … konfigurierten Werte und – falls sie dort nicht konfiguriert sind – die Kernel- oder benutzerbezogenen Vorgaben, wie sie durch das Betriebssystem (letzteres nur für Benutzerdienste, siehe oben) definiert sind.

Tabelle 1. Ressourcenbegrenzungsanweisungen, ihre äquivalenten
Ulimit-Shell-Befehle und die verwandte Einheit

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=.

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.

Tabelle 2. Automatische Verzeichniserstellung und
Umgebungsvariablen

Im Falle von RuntimeDirectory= werden die tiefsten Unterverzeichnisse entfernt, wenn die Unit gestoppt wird. Es ist möglich, in diesem Fall die festgelegten Verzeichnisse zu erhalten, falls RuntimeDirectoryPreserve= auf restart oder yes konfiguriert ist (siehe unten). Die mit StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory= festgelegten Verzeichnisse werden nicht entfernt, wenn die Unit gestoppt wird.

Außer im Fall von ConfigurationDirectory= werden die innersten festgelegten Verzeichnisse dem in User= und Group= festgelegten Benutzer und der Gruppe gehören. Falls die festgelegten Verzeichnisse bereits existieren und ihre besitzenden Benutzer und Gruppe nicht auf die konfigurierten passen, werden alle Dateien und Verzeichnisse unterhalb der festgelegten Verzeichnisse sowie alle Verzeichnisse selbst rekursiv geändert, so dass die Eigentümerschaft auf die konfigurierte passt. Falls die festgelegten Verzeichnisse bereits dem richtigen Benutzer und der richtigen Gruppe gehören werden als Optimierung alle Dateien und Verzeichnisse darunter unverändert gelassen, selbst falls sie nicht auf das angeforderte passen. Die Zugriffsmodi der innersten festgelegten Verzeichnisse wird auf das, was in RuntimeDirectoryMode=, StateDirectoryMode=, CacheDirectoryMode=, LogsDirectoryMode= und ConfigurationDirectoryMode= festgelegt ist, angepasst.

Diese Optionen implizieren BindPaths= für die festgelegten Pfade. Bei der Kombination mit RootDirectory= oder RootImage= werden diese Pfade immer innerhalb des Rechners liegen und von dort in den Dateisystemnamensraum der Unit eingehängt.

Falls DynamicUser= zusammen mit StateDirectory=, CacheDirectory= und LogsDirectory= verwandt wird, wird es leicht geändert: die Verzeichnisse werden unterhalb /var/lib/private, /var/cache/private bzw. /var/log/private erstellt, die Verzeichnisse des Rechners sind, die für nicht privilegierte Benutzer nicht zugreifbar sind. Dadurch wird sichergestellt, dass Zugriff auf diese Verzeichnisse nicht über das Recyclen dynamischer Benutzerkennungen möglich ist. Symbolische Links werden erstellt, um diese Unterschiede im Verhalten zu verstecken. Daher tauchen sowohl aus Sicht des Rechners als auch aus innerhalb der Unit die relevanten Verzeichnisse immer direkt unter /var/lib, /var/cache und /var/log auf.

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).

Beispiel: Falls eine Systemdienste-Unit

RuntimeDirectory=foo/bar baz

enthält, erstellt der Diensteverwalter /run/foo (falls es noch nicht existiert), /run/foo/bar und /run/baz. Die Verzeichnisse /run/foo/bar und /run/baz außer /run/foo gehören dem Benutzer und der Gruppe, die in User= und Group= festgelegt sind und werden entfernt, wenn der Dienst gestoppt wird.

Beispiel: Falls eine Systemdienste-Unit

RuntimeDirectory=foo/bar
StateDirectory=aaa/bbb ccc

enthält, dann wird die Umgebungsvariable »RUNTIME_DIRECTORY« mit »/run/foo/bar« und »STATE_DIRECTORY« mit »/var/lib/aaa/bbb:/var/lib/ccc« gesetzt.

In ReadWritePaths= aufgeführte Pfade sind von innerhalb des Namensraums mit den gleichen Zugriffsmodi wie von außerhalb zugreifbar. In ReadOnlyPaths= aufgeführte Pfade sind nur lesbar zugreifbar, Schreiben wird abgelehnt, selbst falls die normale Dateizugriffssteuerung dies erlauben würde. Schachteln Sie ReadWritePaths= innerhalb von ReadOnlyPaths=, um schreibbare Unterverzeichnisse innerhalb nur lesbarer Verzeichnisse bereitzustellen. Verwenden Sie ReadWritePaths=, um bestimmte Pfade für den Schreibzugriff freizuschalten, falls ProtectSystem=strict verwandt wird.

In InaccessiblePaths= aufgeführte Pfade, einschließlich der Dateisystemhierarchie darunter, werden für Prozesse innerhalb des Namensraums unzugreifbar gemacht. Dies könnte restriktiver als gewünscht sein, da es nicht möglich ist, darin ReadWritePaths=, ReadOnlyPaths=, BindPaths= oder BindReadOnlyPaths= zu verschachteln. Für eine flexiblere Option siehe TemporaryFileSystem=.

Es können auch Pfade, die keine Verzeichnisse sind, angegeben werden. Diese Optionen können mehr als einmal angegeben werden, dann haben alle aufgeführten Pfade von innerhalb des Namensraums aus beschränkten Zugriff. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste zurückgesetzt und alle vorherigen Zuweisungen haben keinen Effekt.

Pfaden in ReadWritePaths=, ReadOnlyPaths= und InaccessiblePaths= kann ein »-« vorangestellt werden, wodurch sie ignoriert werden, falls sie nicht existieren. Falls ihnen »+« vorangestellt wird, werden die Pfade als relativ zum Wurzelverzeichnis der Unit akzeptiert, wie dies mit RootDirectory=/RootImage= konfiguriert ist, statt relativ zum Wurzelverzeichnis des Rechners (siehe oben). Wenn Sie »-« und »+« auf dem gleichen Pfad kombinieren, verwenden Sie »-« zuerst und danach »+«.

Beachten Sie, dass diese Einstellungen die Ausbreitung von Einhängungen von den Prozessen einer Unit zum Rechner abtrennt. Dies bedeutet, dass diese Einstellung nicht für Dienste benutzt werden darf, die in der Lage sein müssen, Einhängepunkte im Haupteinhängenamensraum zu installieren. Die ReadWritePaths=- und ReadOnlyPaths=-Ausbreitung in die andere Richtung ist nicht betroffen, d.h. Einhängungen, die im Rechner erstellt werden, tauchen im Allgemeinen im Namensraum der Unit auf und Einhängungen, die auf dem Rechner entfernt werden, verschwinden auch dort. Beachten Sie insbesondere, dass die Einhängeausbreitung vom Rechner zu der Unit dazu führt, dass unveränderte Einhängungen im Namensraum der Unit erstellt werden, d.h. schreibbare Einhängungen, die auf dem Rechner auftauchen, werden auch im Namensraum der Unit schreibbar sein, selbst wenn sie zu einem Pfad fortgepflanzt 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 Verriegelung 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.

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. Siehe das nachfolgende Beispiel.

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.

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.

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.

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.

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.

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, das sie häufig für lokale Kommunikation verwandt wird, einschließlich für die syslog(2)-Protokollierung.

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.

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 Forpflanzungsmodus 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 werden.

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.

Beachten Sie, dass auf Systemen, die mehrere ABIs unterstützen (wie X86/X86-64), empfohlen wird, alternative ABIs für Dienste zu deaktivieren, so dass sie nicht zur Umgehung der Einschränkungen dieser Option verwandt werden können. Insbesondere wird empfohlen, diese Option mit SystemCallArchitectures=native oder ähnlichem zu kombinieren.

Beachten Sie, dass strenge Systemaufruffilterung die Ausführungs- und Fehlerbehandlungs-Code-Pfade des Diensteaufrufs beeinflussen können. Insbesondere wird der Zugriff auf den Systemaufruf execve für die Ausführung des Diensteprogrammes benutzt — falls er blockiert ist, wird der Diensteaufruf notwendigerweise fehlschlagen. Falls auch die Ausführung des Diensteprogramms aus irgendwelchen Gründen fehlschlägt (beispielsweise fehlendes Diensteprogramm) könnte die Fehlerbehandlungslogik Zugriff auf eine zusätzliche Gruppen an Systemaufrufen benötigen, um diesen Fehlschlag korrekt zu verarbeiten und zu protokollieren. Es könnte notwendig sein, temporär die Systemaufruffilter zu deaktivieren, um die Fehlersuche bei solchen Fehlschlägen zu vereinfachen.

Falls Sie beide Arten dieser Option (d.h. explizite Freischaltung und Ausschlussliste) festlegen, wird die erste angetroffene Vorrang haben und die Standardaktion festlegen (Beendigung oder Bestätigung eines Systemaufrufs). Dann wird das nächste Auftreten dieser Option die Liste der Systemaufrufe zu der Menge der gefilterten Systemaufrufe hinzufügen oder aus dieser löschen, abhängig von seiner Art und der Standardaktion. (Falls Sie beispielsweise mit einer expliziten Freischaltung von read und write beginnen und direkt danach eine Ausschlussliste mit write hinzufügen, dann wird write aus der Menge entfernt.)

Da die Anzahl der möglichen Systemaufrufe groß ist, werden vordefinierte Gruppen von Systemaufrufen bereitgestellt. Eine Gruppe beginnt mit dem Zeichen »@«, gefolgt vom Namen der Gruppe.

Tabelle 3. Derzeit vordefinierte Systemaufrufgruppen

Beachten Sie, dass neue Systemaufrufe zu den obigen Gruppen hinzugefügt werden könnten, wenn neue Systemaufrufe zu dem Kernel hinzugefügt werden. Die Inhalte dieser Gruppen können sich auch zwischen Systemd-Versionen unterscheiden. Zusätzlich hängt die Liste der Systemaufrufe auch von der Kernelversion und der Architektur, für die Systemd kompiliert wurde, ab. Verwenden Sie systemd-analyze syscall-filter, um die tatsächliche Liste der Systemaufrufe in jedem Filter aufzuführen.

Im allgemeinen ist das explizite Erlauben von Systemaufrufen (statt einer Ausschlussliste) der sichere Betriebsmodus. Es wird empfohlen, für alle langlaufenden Systemdienste eine Liste explizit erlaubter Systemaufrufe zu erzwingen. Insbesondere sind die nachfolgenden Zeilen eine relativ sichere grundlegende Wahl für den Großteil der Systemdienste:

[Service]
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

Es wird empfohlen, die Dateisystem-Namensraum-bezogenen Optionen mit SystemCallFilter=~@mount zu kombinieren, um zu verhindern, dass die Prozesse der Unit die Abbildungen rückgängig machen. Insbesondere sind dies die Optionen PrivateTmp=, PrivateDevices=, ProtectSystem=, ProtectHome=, ProtectKernelTunables=, ProtectControlGroups=, ReadOnlyPaths=, InaccessiblePaths= und ReadWritePaths=.

Falls diese Einstellung verwandt wird, wird den Prozessen dieser Unit nur der Aufruf nativer Systemaufrufe erlaubt und Systemaufrufe der festgelegten Architektur. Für die Zwecke dieser Option wird die Architektur X32 so behandelt, dass sie die Systemaufrufe von X86-64 enthält. Allerdings erfüllt diese Einstellung auf X32 weiterhin ihren Zweck, wie unten dargestellt.

Systemaufruffilterung ist nicht auf allen Architekturen wirksam. Beispielsweise ist auf X86 aufgrund von ABI-Einschränkungen das Filtern von Netz-Socket-bezogenen Aufrufen nicht möglich, eine Einschränkung, die X86-64 allerdings nicht hat. Auf Systemen, die mehrere ABI gleichzeitig unterstützen, wie X86/X86-64, wird daher empfohlen, die Gruppe der erlaubten Systemaufrufarchitekturen einzuschränken, so dass das sekundäre ABI nicht dazu verwandt werden kann, die auf das native ABI des Systems auferlegten Einschränkungen zu umgehen. Insbesondere ist das Setzen von SystemCallArchitectures=native für das Deaktivieren nichtnativer ABIs eine gute Wahl.

Systemaufrufarchitekturen können auch systemweit mittels der Option SystemCallArchitectures= in der globalen Konfiguration eingeschränkt werden. Siehe systemd-system.conf(5) für Details.

Beispiel:

Environment="VAR1=Wort1 Wort2" VAR2=Wort3 "VAR3=$Wort 5 6"

ergibt drei Variablen »VAR1«, »VAR2«, »VAR3« mit den Werten »Wort1 Wort2«, »Wort3«, »$Wort 5 6«.

Siehe environ(7) für Details über Umgebungsvariablen.

Beachten Sie, dass Umgebungsvariablen nicht dazu geeignet sind, Geheimnisse (wie Passwörter, Schlüsselmaterial, …) an Diensteprozesse weiterzugeben. Für eine Unit gesetzte Umgebungsvariablen können von nicht privilegierten Clients wie D-Bus-IPC eingesehen werden und werden im Allgemeinen nicht als Daten betrachtet, die geschützt werden müssen. Desweiteren werden Umgebungsvariablen den Prozessbaum heruntergereicht, auch über Sicherheitsgrenzen (wie Setuid/Setgid-Programme) hinweg und könnten daher zu Prozessen durchsickern, die keinen Zugriff auf die geheimen Daten haben sollen.

Das übergebene Argument sollte ein absoluter Dateiname oder ein Platzhalterausdruck sein, dem optional »-« vorangestellt werden kann, um anzuzeigen, das sie nicht gelesen und keine Fehler- oder Warnmeldung protokolliert wird, falls sie nicht existiert. Diese Option kann mehr als einmal festgelegt werden, in diesem Fall werden alle festgelegten Dateien gelesen. Falls der Option die leere Zeichenkette zugewiesen wird, wird die Liste der zu lesenden Dateien zurückgesetzt und alle vorherigen Zuweisungen haben keine Wirkung.

Die mit dieser Anweisung aufgeführten Dateien werden kurz vor der Ausführung des Prozesses gelesen (genauer gesagt, nachdem alle Prozesse eines vorherigen Unit-Zustandes beendet wurden. Dies bedeutet, dass Sie diese Dateien in einem Unit-Zustand erstellen und sie mit dieser Option in dem nächsten lesen können).

Einstellungen von diesen Dateien setzen mit Environment= vorgenommene Einstellungen außer Kraft. Falls die gleiche Variable zweimal von diesen Dateien gesetzt wird, werden die Dateien in der festgelegten Reihenfolge eingelesen und spätere Einstellungen werden die früheren Einstellungen außer Kraft setzen.

Variablen, die aufgrund dieser Einstellung für aufgerufene Prozesse gesetzt werden, unterliegen der Möglichkeit, durch solche, die mit Environment= oder EnvironmentFile= konfiguriert wurden, außer Kraft gesetzt zu werden.

Beispiel:

PassEnvironment=VAR1 VAR2 VAR3

übergibt die drei Variablen »VAR1«, »VAR2«, »VAR3« mit den für diese Variablen in PID1 gesetzten Werten.

Siehe environ(7) für Details über Umgebungsvariablen.

Siehe environ(7) für Details über Umgebungsvariablen.

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 ist, siehe unten) verbunden und der ausgeführte Prozess wird der steuernde Prozess des Terminals. Falls das Terminal bereits durch einen anderen Prozess gesteuert wird, wartet der ausgeführte Prozess, bis der derzeit steuernde Prozess das Terminal freigibt.

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 übergebenen 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 besondere Datei beziehen kann. Falls ein AF_UNIX-Socket in dem Dateisystem festgelegt ist, wird mit ihm ein Strom-Socket verbunden. Letzteres ist nützlich, um die Standardeingabe eines beliebigen Prozesses mit einem beliebigen Systemdienst zu verbinden.

Die Option »socket« ist nur in Socket-aktivierten Diensten gültig und es muss in der relevanten Socket-Unit-Datei (siehe systemd.socket(5) für Details) Accept=yes gesetzt oder nur ein einzelnes Socket spezifiziert sein. Falls diese Option gesetzt ist, wird die Standardeingabe mit dem Socket, aus dem der Dienst aktiviert wurde, verbunden. Dies ist hauptsächlich für die Kompatibilität mit Daemons nützlich, die für die Verwendung mit der traditionellen inetd(8)-Socket-Daemon-Aktivierung entwickelt wurden.

Die Option fd:Name verbindet die Standardeingabe mit einem durch die Socket-Unit bereitgestellten bestimmten, benannten Dateideskriptor. Der Name kann als Teil dieser Option festgelegt werden, gefolgt vom Zeichen »:« (z.B. »fd:foobar«). Falls kein Name festgelegt ist, wird der Name »stdin« impliziert (d.h. »fd« ist äquivalent zu »fd:stdin«). Mindestens eine Socket-Unit, die den festgelegten Namen definiert, muss über die Option Sockets= bereitgestellt werden und der Dateideskriptorname darf sich vom Namen der Socket-Unit, die ihn enthält, unterscheiden. Falls mehrere Treffer gefunden werden, wird der erste verwandt. Siehe FileDescriptorName= in systemd.socket(5) für weitere Details über benannte Dateideskriptoren und ihrer Sortierung.

Diese Einstellung ist standardmäßig null.

Beachten Sie, dass Dienste, die DefaultDependencies=no festlegen und StandardInput= oder StandardOutput= mit tty/tty-force/tty-fail verwenden, After=systemd-vconsole-setup.service festlegen sollten, um sicherzustellen, dass die TTY-Initialisierung abgeschlossen ist, bevor sie starten.

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 zwei speziellen unten aufgeführten Optionen sind daher eine Obermenge dieser Option.

syslog verbindet die Standardausgabe mit dem Systemprotokollierdienst syslog(3), zusätzlich zum Journal. Beachten Sie, dass der Journal-Daemon normalerweise so konfiguriert ist, dass er alles, was er empfängt, sowieso zum Syslog weiterleitet, wodurch diese Option in diesem Fall keinen Unterschied zu journal darstellt.

kmsg verbindet die Standardeingabe mit dem Kernelprotkollpuffer, 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, syslog+console und kmsg+console arbeiten auf eine ähnliche Art wie die drei 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 ählich der identischen, oben dargestellten Option StandardInput=. 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 Stromverbindung für sowohl Ein- als auch Ausgabe erstellt wird.

append:Pfad ist ähnlich zu file:path oben, es öffnet die Datei aber im Anhängemodus.

socket verbindet die Standardausgabe zu einem mittels Socket-Aktivierung erlangten Socket. Die Semantik ist ähnlich der identischen, oben dargestellten Option StandardInput=.

Die Option fd:Name verbindet die Standardausgabe mit einem bestimmten benannten, durch eine Socket-Unit bereitgestellten Dateideskriptor. Es kann als Teil dieser Option ein Name, gefolgt von einem »:«-Zeichen, festgelegt werden (z.B. »fd:foobar«). Falls kein Name festgelegt ist, wird der Name »stdout« impliziert (d.h. »fd« ist äquivalent zu »fd:stdout«). Mindestens eine Socket-Unit, die den festgelegten Namen definiert, muss über die Option Sockets= bereitgestellt werden und der Dateideskriptorname darf sich vom Namen der Socket-Unit, die ihn enthält, unterscheiden. Falls mehrere Treffer gefunden werden, wird der erste verwandt. Siehe FileDescriptorName= in systemd.socket(5) für weitere Details über benannte Dateideskriptoren und ihrer Sortierung.

Falls die Standardausgabe (oder die Fehlerausgabe, siehe unten) einer Unit mit dem Journal, dem Syslog 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-Strom-Socket und keine PIPE oder FIFO, die erneut geöffnet werden kann, sein wird. Das bedeutet, dass bei der Ausführung von Shell-Skripten die Konstruktion »echo "hello" > /dev/stderr« zum Schreiben von Text nach Stderr nicht funktionieren wird. Um dies zu entschärfen, verwenden Sie stattdessen die Konstruktion »echo "hello" >&2«, die größtenteils äquivalent ist und diesen Fallstrick vermeidet.

Der Vorgabewert dieser Einstellung ist der mit DefaultStandardOutput= in systemd-system.conf(5) gesetzte Wert, der standardmäßig journal ist. Beachten Sie, dass dieser Parameter zum Hinzufügen zusätzlicher Abhängigkeiten führen kann (siehe oben).

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= akzeptiert beliebige textuelle Daten. C-artige Maskierungen für besondere Zeichen sowie die normalen »%«-Kennzeichner werden aufgelöst. Jedes Mal, wenn diese Einstellung benutzt wird, wird der festgelegte Text an den Unit-bezogenen Datenpuffer, gefolgt von einem Zeilenumbruchzeichen, angehängt (daher hängt jeder Einsatz eine neue Zeile an das Ende des Puffers an). Beachten Sie, dass einleitende und abschließende Leerraumzeichen von mit dieser Option konfigurierten Zeilen entfernt werden. Falls eine leere Zeile festgelegt wird, wird der Puffer bereinigt (daher sollte ein zusätzliches »\n« an das Ende oder den Anfang einer Zeile eingefügt werden, um eine leere Zeile einzufügen).

StandardInputData= akzeptiert beliebige, in Base64[4] kodierte binäre Daten. Es werden keine Maskiersequenzen oder Kennzeichner aufgelöst. Sämtliche Leeraumzeichen in der kodierten Version werden während der Dekodierung ignoriert.

Beachten Sie, dass StandardInputText= und StandardInputData= auf dem gleichen Datenpuffer arbeiten und gemischt werden können, um sowohl binäre als auch textuelle Daten für den gleichen Eingabedatenstrom zu konfigurieren. Die textuellen oder binären Daten werden genau in der Reihenfolge zusammengefügt, in der sie in der Unit-Datei auftauchen. Wird einem eine leere Zeichenkette zugewiesen, wird der Datenpuffer zurückgesetzt.

Bitte beachten Sie, dass lange Unit-Dateieinstellungen in mehrere Zeilen aufgeteilt werden können, um die Lesbarkeit zu erhalten. Hierzu wird jeder Zeile (außer der letzten) ein Zeichen »\« vorangestellt (siehe systemd.unit(5) für Details). Dies ist insbesondere für große Daten, die mit diesen Optionen konfiguriert werden, nützlich. Beispiel:

…
StandardInput=data
StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl \
                  LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \
                  dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug \
                  enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \
                  SWNrZSEK
…

Falls sowohl die Standardausgabe als auch der Standardfehler des ausgeführten Prozesses mit dem Journal über ein Strom-Socket verbunden sind, wird diese Umgebungsvariable Informationen über den Standardfehlerstrom enthalten, da dies normalerweise das bevorzugte Ziel für Protokolldaten ist. (Beachten Sie, dass typischerweise der gleiche Strom sowohl für die Standardausgabe als auch den Standardfehler verwandt wird und daher die Umgebungsvariable sehr wahrscheinlich Geräte- und Inodeinformationen enthalten wird, die auf beide Stromdateideskriptoren passt.)

Diese Umgebungsvariable ist hauptsächlich nützlich, um Diensten zu erlauben, ihr verwandtes Protokollierungsprotokoll optional (mittels sd_journal_print(3) und anderer Funktionen) auf das native Journal-Protokoll anzuheben, falls ihre Standardausgabe oder Standardfehlerausgabe sowieso mit dem Journal verbunden ist. Damit wird die Lieferung von strukturierten Metadaten zusammen mit den protokollierten Nachrichten ermöglicht.

Tabelle 4. Definierte $SERVICE_RESULT-Werte

Diese Umgebungsvariable ist nützlich, um den Fehlschlag oder die erfolgreiche Beendigung eines Dienstes zu überwachen. Obowohl diese Variable sowohl in ExecStop= und ExecStopPost= verfügbar ist, ist es normalerweise eine bessere Wahl, die Überwachungswerkzeuge in letzterer zu platzieren, da erstere nur für Dienste aufgerufen wird, die ihren Start korrekt verwaltet haben und letztere sowohl Dienste abdeckt, die während ihres Startens fehlschlugen als auch solche, die während ihrer Laufzeit fehlschlugen.

Tabelle 5. Zusammenfassung der möglichen Variablenwerte für
Diensteergebnisse