.\" -*- coding: UTF-8 -*- '\" t .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH SYSTEMD\&.EXEC 5 "" "systemd 247" systemd.exec .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH BEZEICHNUNG systemd.exec \- Konfiguration der Ausführungsumgebung .SH ÜBERSICHT .PP \fIDienst\fP\&.service, \fISocket\fP\&.socket, \fIEinhängung\fP\&.mount, \fIAuslagerung\fP\&.swap .SH BESCHREIBUNG .PP Unit\-Konfigurationsdateien für Dienste, Sockets, Einhängepunkte und Auslagerungsgeräte nutzen eine Teilmenge der Konfigurationsoptionen, die die Ausführungsumgebung von gestarteten Prozessen definieren\&. .PP Diese Handbuchseite listet die Konfigurationsoptionen auf, die von diesen vier Unit\-Typen gemeinsam benutzt werden\&. Siehe \fBsystemd.unit\fP(5) für die Konfiguration der von allen Unit\-Typen gemeinsam benutzten Optionen und \fBsystemd.service\fP(5), \fBsystemd.socket\fP(5), \fBsystemd.swap\fP(5) und \fBsystemd.mount\fP(5) für weitere Informationen über die Konfigurationsdateioptionen, die für jeden Unit\-Typen spezifisch sind\&. Die ausführungsspezifischen Konfigurationsoptionen werden in den Abschnitten [Service], [Socket], [Mount] oder [Swap] konfiguriert, abhängig vom Unit\-Typ\&. .PP Zusätzlich werden Optionen, die verfügbare Ressourcen mittels Linux Control Groups (cgroups) steuern, in \fBsystemd.resource\-control\fP(5) aufgeführt\&. Diese Optionen ergänzen die hier aufgeführten Optionen\&. .SH "IMPLIZITE ABHÄNGIGKEITEN" .PP Einige Ausführungsparameter führen zur Ergänzung von zusätzlichen, automatischen Abhängigkeiten: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Units mit gesetzten \fIWorkingDirectory=\fP, \fIRootDirectory=\fP, \fIRootImage=\fP, \fIRuntimeDirectory=\fP, \fIStateDirectory=\fP, \fICacheDirectory=\fP, \fILogsDirectory=\fP oder \fIConfigurationDirectory=\fP erhalten automatisch Abhängigkeiten vom Typ \fIRequires=\fP und \fIAfter=\fP von allen für den Zugriff auf die festgelegten Pfade notwendigen Einhängepunkten\&. Dies ist äquivalent zur expliziten Auflistung in \fIRequiresMountsFor=\fP\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Ähnlich erhalten Einhänge\-Units mit aktiviertem \fIPrivateTmp=\fP automatisch Abhängigkeiten von allen Einhängungen, die notwendig sind, auf /tmp/ und /var/tmp/ zuzugreifen\&. Sie werden auch automatische Abhängigkeiten \fIAfter=\fP von \fBsystemd\-tmpfiles\-setup.service\fP(8) erhalten\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Units, deren Standardausgabe oder Fehlerausgabe mit dem \fBjournal\fP oder \fBkmsg\fP (oder ihrer Kombination mit Konsolenausgabe, siehe unten) verbunden ist, erlangen automatisch Abhängigkeiten vom Typ \fIAfter=\fP von systemd\-journald\&.socket\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Units, die \fILogNamespace=\fP verwenden, werden automatisch Ordnungs\- und Bedingungsabhängigkeiten auf die zwei zugeordneten Socket\-Units mit systemd\-journald@\&.service\-Instanzen erlangen\&. .RE .SH PFADE .PP 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\&. .PP \fIWorkingDirectory=\fP .RS 4 Akzeptiert einen Verzeichnispfad, der relativ zu dem durch \fIRootDirectory=\fP festgelegten Wurzelverzeichnis des Dienstes ist, oder den besonderen Wert »~«\&. Setzt das Arbeitsverzeichnis für ausgeführte Prozesse\&. Falls auf »~« gesetzt, wird das Home\-Verzeichnis des in \fIUser=\fP festgelegten Benutzers verwandt\&. Falls nicht gesetzt, ist dies standardmäßig das Wurzelverzeichnis, falls Systemd als eine Systeminstanz läuft und das Home\-Verzeichnis des respektiven Benutzers, falls es als Benutzer läuft\&. Falls der Einstellung das Zeichen »\-« vorangestellt wird, wird ein fehlendes Arbeitsverzeichnis nicht als fatal betrachtet\&. Falls \fIRootDirectory=\fP/\fIRootImage=\fP nicht gesetzt ist, dann ist \fIWorkingDirectory=\fP relativ zu der Wurzel des Systems, das den Diensteverwalter betreibt\&. Beachten Sie, dass das Setzen dieses Parameters die Hinzunahme von zusätzlichen Abhängigkeiten (siehe oben) auslösen kann\&. .RE .PP \fIRootDirectory=\fP .RS 4 Akzeptiert einen Verzeichnispfad, der relativ zum Wurzelverzeichnis des Rechners (d\&.h\&. der Wurzel des Systems, auf dem der Diensteverwalter läuft) ist\&. Setzt mit dem Systemaufruf \fBchroot\fP(2) das Wurzelverzeichnis für ausgeführte Prozesse. Falls dies verwandt wird, muss sichergestellt werden, dass das Prozessprogramm und alle seine zugehörigen Dateien in dem \fBchroot()\fP\-Gefängnis verfügbar sind\&. Beachten Sie, dass das Setzen dieses Parameters die Hinzunahme von zusätzlichen Abhängigkeiten (siehe oben) auslösen kann\&. .sp Die Einstellungen \fIMountAPIVFS=\fP und \fIPrivateUsers=\fP sind inbesondere im Zusammenhang mit \fIRootDirectory=\fP nützlich\&. Für Details siehe unten\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIRootImage=\fP .RS 4 Akzeptiert einen Pfad zu einem Blockgeräteknoten oder einer regulären Datei als Argument\&. Dieser Aufruf ist ähnlich \fIRootDirectory=\fP, hängt allerdings eine Dateisystemhierarchie aus einem Blockgeräteknoten oder einer Loopback\-Datei anstatt eines Verzeichnisses ein\&. Der Geräteknoten oder die Dateisystemabbilddatei müssen ein Dateisystem ohne Partitionstabelle enthalten oder ein Dateisystem innerhalb einer MBR/MS\-DOS\- oder GPT\-Partitionstabelle mit nur einer einzelnen Linux\-kompatiblen Partition oder eine Gruppe von Dateisystemen innerhalb einer GPT\-Partitionstabelle, die der \m[blue]\fBSpezifikation für auffindbare Partitionen\fP\m[]\&\s-2\u[1]\d\s+2 folgt\&. .sp Wenn \fIDevicePolicy=\fP auf »closed« oder »strict« gesetzt ist oder auf »auto« und \fIDeviceAllow=\fP gesetzt ist, dann fügt diese Einstellung /dev/loop\-control mit Modus \fBrw\fP, »block\-loop« und »block\-blkext« mit Modus \fBrwm\fP zu \fIDeviceAllow=\fP hinzu\&. Siehe \fBsystemd.resource\-control\fP(5) für die Details über \fIDevicePolicy=\fP oder \fIDeviceAllow=\fP\&. Siehe auch nachfolgendes \fIPrivateDevices=\fP, da sie die Einstellungen von \fIDevicePolicy=\fP ändern könnte\&. .sp Units, die \fIRootImage=\fP verwenden, erlangen automatisch eine \fIAfter=\fP\-Abhängigkeit auf systemd\-udevd\&.service\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIRootImageOptions=\fP .RS 4 Akzeptiert eine Kommata\-getrennte Liste von Einhängeoptionen, die bei mit \fIRootImage=\fP 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 \fBmount\fP(8) für eine Liste gültiger Einhängeoptionen\&. .sp Gültige Partitionsnamen folgen der \m[blue]\fBSpezifikation für auffindbare Partitionen\fP\m[]\&\s-2\u[1]\d\s+2\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&1.\ \&Akzeptierte Partitionsnamen\fP .TS allbox tab(:); lB. T{ Partitionsname T} .T& l l l l l l l l l. T{ root T} T{ root\-secondary T} T{ home T} T{ srv T} T{ esp T} T{ xbootldr T} T{ tmp T} T{ var T} T{ usr T} .TE .sp 1 Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIRootHash=\fP .RS 4 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 \fIRootVerity=\fP 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 \fBxattr\fP(7)), dann wird der Wurzel\-Hash daraus gelesen, auch als hexdezimal formatierte Zeichen\&. Falls das erweiterte Dateiattribut nicht gefunden wird (oder vom zugrundeliegenden Dateisystem nicht 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\&. .sp 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\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIRootHashSignature=\fP .RS 4 Akzeptiert eine PKCS7\-Signatur der Option \fIRootHash=\fP 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\&. .sp 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\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIRootVerity=\fP .RS 4 Akzeptiert einen Pfad zu einer Datenintegritäts\- (dm\-verity\-)Datei\&. Diese Option aktiviert Datenintegritätsüberprüfungen mittels dm\-verity, falls \fIRootImage=\fP 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\&. .sp 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 \m[blue]\fBSpezifikation für auffindbare Partitionen\fP\m[]\&\s-2\u[1]\d\s+2 umsetzen\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIMountAPIVFS=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls eingeschaltet, wird ein privater Einhängenamensraum für die Prozesse der Unit erstellt und die API\-Dateisysteme /proc/, /sys/ und /dev/ darin eingehängt, außer sie sind bereits eingehängt\&. Beachten Sie, dass diese Option keinen Effekt zeigt, außer sie wird zusammen mit \fIRootDirectory=\fP/\fIRootImage=\fP verwandt, da diese drei Einhängungen im Allgemeinen im Rechner sowieso eingehängt sind und außer wenn das Wurzelverzeichnis geändert wird, der private Einhängenamensraum eine 1:1\-Kopie des Rechners sein wird und diese drei Einhängungen enthalten wird\&. Beachten Sie, dass das /dev/\-Dateisystem des Rechners mit »bind« eingehängt wird, falls diese Option ohne \fIPrivateDevices=\fP verwandt wird\&. Um den Dienst mit einer privaten, minimalen Version von /dev/ auszuführen, kombinieren Sie diese Option mit \fIPrivateDevices=\fP\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIProtectProc=\fP .RS 4 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/\fIPID\fP) 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 \fBptrace()\fP 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 \m[blue]\fBDas /proc\-Dateisystem\fP\m[]\&\s-2\u[2]\d\s+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\&. Sie kann auch nicht für Dienste verwandt werden, die auf Metainformationen von Prozessen anderer Benutzer zugreifen müssen\&. Diese Option impliziert \fIMountAPIVFS=\fP\&. .sp Falls der Kernel keine einhängepunktbezogenen Einhängeoptionen \fBhidepid=\fP 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\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIProcSubset=\fP .RS 4 Akzeptiert »all« (die Vorgabe) und »pid«\&. In letzterem Fall 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 \m[blue]\fBDas /proc\-Dateisystem\fP\m[]\&\s-2\u[2]\d\s+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\&. .sp Ganz ähnlich zu obigem \fIProtectProc=\fP 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 \fIMountAPIVFS=\fP\&. Diese Einstellung wird wie bei \fIProtectProc=\fP auch sauber beendet, falls der Kernel die Einhängeoption »subset=« von »procfs« nicht unterstützt.\&. .RE .PP \fIBindPaths=\fP, \fIBindReadOnlyPaths=\fP .RS 4 Konfiguriert Unit\-spezifische Bind\-Einhängungen\&. Eine Bind\-Einhängung macht eine bestimmte Datei oder Verzeichnis an einem zusätzlichen Ort in der Betrachtung der Unit verfügbar\&. Alle mit dieser Option erstellten Bind\-Einhängungen sind für die Unit spezifisch und nicht innerhalb der Einhängetabelle des Rechners sichtbar\&. Diese Option erwartet eine Leerraum\-getrennte Liste von Bind\-Einhängedefinitionen\&. Jede Definition besteht aus einem durch Doppelpunkte getrennten Tripel von Quellpfad, Zielpfad und Optionszeichenkette, wobei die letzteren zwei optional sind\&. Falls nur ein Quellpfad festgelegt wird, wird angenommen, dass Quelle und Ziel identisch sind\&. Die Optionszeichenkette kann entweder »rbind« oder »norbind« sein, um eine rekursive oder nichtrekursive Bind\-Einhängung zu konfigurieren\&. Falls der Zielpfad ausgelassen wird, muss auch die Optionszeichenkette ausgelassen werden\&. Jeder Bind\-Einhängungsdefinition kann »\-« vorangestellt werden, wodurch sie ignoriert wird, falls der Quellpfad nicht existiert\&. .sp \fIBindPaths=\fP erstellt reguläre, schreibbare Bind\-Einhängungen (außer die Quelldateisystemeinhängung ist bereits nur\-lesbar markiert), während \fIBindReadOnlyPaths=\fP nur\-lesbare Bind\-Einhängungen erstellt\&. Diese Einstellungen können mehr als einmal verwandt werden, jede Verwendung hängt sich an die Liste der Bind\-Einhängungen der Unit an\&. Falls zu einer dieser zwei Optionen die leere Zeichenkette zugewiesen wird, wird die gesamte Liste an vorher definierten Bind\-Einhängungen dazu zurückgesetzt\&. Beachten Sie, dass in diesem Fall sowohl die nur\-lesbaren als auch die regulären Bind\-Einhängungen zurückgesetzt werden, unabhängig davon, welche der zwei Einhängungen verwandt wird\&. .sp Diese Option ist besonders nützlich, wenn \fIRootDirectory=\fP/\fIRootImage=\fP verwandt wird\&. In diesem Fall bezieht sich der Quellpfad auf einen Pfad im Dateisystem des Rechners, während der Zielpfad sich auf einen Pfad unterhalb des Wurzelverzeichnisses der Unit bezieht\&. .sp 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 \fIInaccessiblePaths=\fP oder unter /home/ und anderen geschützten Verzeichnissen verschachtelt sind, zu verwenden, falls \fIProtectHome=yes\fP angegeben ist\&. Stattdessen sollte \fITemporaryFileSystem=\fP mit »:ro« oder \fIProtectHome=tmpfs\fP verwandt werden\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIMountImages=\fP .RS 4 Diese Einstellung ist ähnlich zu \fIRootImage=\fP\&. 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\&. .sp 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 \fIRootImageOptions=\fP identisch\&. .sp 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 »\e:« maskiert werden\&. Der Geräteknoten oder das Dateisystemabbild muss den gleichen Regeln folgen, wie diese für \fIRootImage=\fP 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\&. .sp 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\&. .sp 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 \fIInaccessiblePaths=\fP oder unter /home/ und anderen geschützten Verzeichnissen verschachtelt sind, zu verwenden, falls \fIProtectHome=yes\fP angegeben ist\&. .sp Wenn \fIDevicePolicy=\fP auf »closed« oder »strict« gesetzt ist oder auf »auto« und \fIDeviceAllow=\fP gesetzt ist, dann fügt diese Einstellung /dev/loop\-control mit Modus \fBrw\fP, »block\-loop« und »block\-blkext« mit Modus \fBrwm\fP zu \fIDeviceAllow=\fP hinzu\&. Siehe \fBsystemd.resource\-control\fP(5) für die Details über \fIDevicePolicy=\fP oder \fIDeviceAllow=\fP\&. Siehe auch nachfolgendes \fIPrivateDevices=\fP, da sie die Einstellungen von \fIDevicePolicy=\fP ändern könnte\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .SH ZUGANGSDATEN .PP Diese Optionen sind nur für Systemdienste verfügbar und werden nicht für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstützt\&. .PP \fIUser=\fP, \fIGroup=\fP .RS 4 Setzt den UNIX\-Benutzer oder die \-Gruppe, unter der der Prozess ausgeführt wird\&. Akzeptiert einen einzelnen Benutzer\- oder Gruppennamen oder eine numerische Kennung als Argument\&. Für Systemdienste (Dienste, die vom Systemdiensteverwalter, d\&.h\&. PID 1, ausgeführt werden) und für Benutzerdienste des Benutzers root (Dienste, die von der Instanz von root von \fBsystemd \-\-user\fP verwaltet werden) ist die Vorgabe »root«, aber \fIUser=\fP kann zur Angabe eines anderen Benutzers verwandt werden\&. Für Benutzerdienste von allen anderen Benutzern ist das Umschalten auf eine andere Benutzeridentität nicht erlaubt, daher ist die einzige gültige Einstellung der Benutzer, unter dem der Diensteverwalter selbst läuft\&. Falls keine Gruppe gesetzt ist, wird die Vorgabegruppe des Benutzers verwandt\&. Diese Einstellung beeinflusst keine Befehle, deren Befehlszeile ein »+« vorangestellt ist\&. .sp Beachten Sie, dass dies nur schwache Einschränkungen in der Namenssyntax von Benutzer/Gruppen erzwingt, aber in vielen Fällen Warnungen erzeugt, bei denen Benutzer\-/Gruppennamen nicht den folgenden Regeln genügen: der angegebene Name sollte 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 als erstes Zeichen nicht erlaubt) bestehen\&. Der Benutzer\-/Gruppenname muss mindestens ein und maximal 31 Zeichen enthalten\&. Diese Einschränkungen erfolgen, um Mehrdeutigkeiten zu vermeiden und um sicherzustellen, dass Benutzer\-/Gruppennamen und Unit\-Dateien zwischen Linux\-Systemen portierbar bleiben\&. Für weitere Details über die akzeptierten Namen und die Namen, über die gewarnt wird, siehe \m[blue]\fBBenutzer\-/Gruppennamesyntax\fP\m[]\&\s-2\u[3]\d\s+2\&. .sp Wenn dies zusammen mit \fIDynamicUser=\fP verwandt wird, wird der angegebene Benutzer\-/Gruppename dynamisch zum Startzeitpunkt des Dienstes zugewiesen und beim Beenden des Dienstes wieder freigegeben \(em außer er ist bereits statisch zugewiesen (siehe unten)\&. Falls \fIDynamicUser=\fP nicht verwandt wird, muss der angegebene Benutzer und die angegebene Gruppe spätestens beim Startmoment des Dienstes statisch in der Benutzerdatenbank erzeugt worden sein, beispielsweise mit der Einrichtung \fBsysusers.d\fP(5), die beim Systemstart oder zum Zeitpunkt der Paketinstallation angewandt wird\&. Falls der Benutzer nicht existiert, wird der Programmaufruf fehlschlagen\&. .sp Falls die Einstellung \fIUser=\fP verwandt wird, wird die Liste der zusätzlichen Gruppen aus der festgelegten Standardgruppenliste des Benutzers, wie dies durch die Benutzer\- und Gruppendatenbank des Systems definiert ist, initialisiert\&. Zusätzliche Gruppen können durch die Einstellung \fISupplementaryGroups=\fP konfiguriert werden (siehe unten)\&. .RE .PP \fIDynamicUser=\fP .RS 4 Akzeptiert einen logischen Parameter\&. Falls gesetzt, wird ein UNIX\-Benutzer\-/Gruppenpaar dynamisch beim Start der Unit erstellt und wieder freigegeben, sobald die Unit beendet wird\&. Der Benutzer und die Gruppe wird nicht zu /etc/passwd oder /etc/group hinzugefügt, sondern zur Laufzeit vorübergehend verwaltet\&. Das Glibc\-NSS\-Modul \fBnss\-systemd\fP(8) stellt eine Integration dieser dynamischen Benutzer/Gruppen in die Benutzer\- und Gruppendatenbanken des Systems bereit\&. Die Benutzer\- und Gruppennamen können mit \fIUser=\fP und \fIGroup=\fP (siehe oben) konfiguriert werden\&. Falls diese Optionen nicht verwandt werden und dynamische Benutzer\-/Gruppenzuweisung für eine Unit aktiviert ist, wird der Name des dynamischen Benutzers/der dynamischen Gruppe implizit vom Unit\-Namen abgeleitet\&. Falls der Unit\-Name ohne die Typ\-Endung als gültiger Benutzername geeignet ist, wird er direkt verwandt, andernfalls wird ein Name, der einen Hash davon integriert, verwandt\&. Falls ein statisch zugewiesener Benutzer oder eine statisch zugewiesene Gruppe des konfigurierten Namens bereits existiert, wird diese verwandt und kein dynamischer Benutzer/keine dynamische Gruppe wird zugewiesen\&. Beachten Sie, dass es notwendig ist, dass der statische Benutzer mit dem Namen bereits existiert, falls \fIUser=\fP angegeben wurde und die statische Gruppe mit dem Namen bereits existiert\&. Entsprechend ist es notwendig, dass die statische Gruppe mit dem Namen bereits existiert, falls \fIGroup=\fP angegeben wurde und der statische Benutzer mit dem Namen bereits existiert\&. Dynamische Benutzer/Gruppen werden aus dem UID/GID\-Bereich 61184…65519 zugewiesen\&. Es wird empfohlen, diesen Bereich für reguläre System\- oder Anmeldebenutzer zu vermeiden\&. Zu jedem Zeitpunkt ist eine UID/GID aus diesem Bereich nur keinem oder einem/einer verwandten Benutzer/Gruppe dynamisch zugewiesen\&. Nachdem eine Unit beendet wurde, werden allerdings UIDs/GIDs wiederbenutzt\&. Es sollte Vorsicht walten gelassen werden, dass jeder Prozess, der als Teil einer Unit läuft, für die dynamische Benutzer/Gruppen aktiviert sind, keine Dateien oder Verzeichnisse, die diesen Benutzern/Gruppen gehören, zurücklässt, da eine andere Unit später die gleiche UID/GID zugewiesen bekommen kann, und daher Zugriff auf diese Dateien oder Verzeichnisse erlangen kann\&. Die Aktivierung von \fIDynamicUser=\fP impliziert \fIRemoveIPC=\fP und \fIPrivateTmp=\fP (was nicht deaktiviert werden kann)\&. Dies stellt sicher, dass die Lebensdauer von IPC\-Objekten und temporären Dateien, die von dem ausgeführten Prozess erstellt wurden, an die Laufzeit des Dienstes gebunden ist, und damit die Lebensdauer des dynamischen Benutzers/der dynamischen Gruppe\&. Da /tmp/ und /var/tmp/ normalerweise die einzigen global schreibbar Verzeichnisse auf einem System sind, stellt dies sicher, dass eine Unit, die dynamische Benutzer\-/Gruppenzuweisungen einsetzt, keine Dateien nach der Beendigung hinterlassen kann\&. Desweiteren werden \fINoNewPrivileges=\fP und \fIRestrictSUIDSGID=\fP implizit aktiviert (und können nicht deaktiviert werden), um sicherzustellen, dass aufgerufene Prozesse nicht aus SUID/SGID\-Dateien oder Verzeichnissen Nutzen ziehen oder diese erstellen können\&. Darüberhinaus sind \fIProtectSystem=strict\fP und \fIProtectHome=read\-only\fP impliziert, die damit verhindern, dass der Dienst an beliebige Dateisystemstellen schreibt\&. Um dem Dienst das Schreiben in bestimmte Verzeichnisse zu erlauben, müssen diese mittels \fIReadWritePaths=\fP explizit erlaubt werden; dabei ist drauf zu achten, dass die Wiederbenutzung von UIDs/GIDs keine Sicherheitsprobleme mit vom Dienst erstellten Dateien hervorruft\&. Verwenden Sie \fIRuntimeDirectory=\fP (siehe unten), um dem Dienst ein schreibbares Laufzeitverzeichnis zuzuweisen, das von dem dynamischen Benutzer/der dynamischen Gruppe besessen und automatisch beim Beenden der Unit entfernt wird\&. Verwenden Sie \fIStateDirectory=\fP, \fICacheDirectory=\fP und \fILogsDirectory=\fP, um eine Gruppe an schreibbaren Verzeichnissen für einen bestimmten Zweck dem Dienst zuzuweisen und dabei sicherzustellen, dass sie vor Schwachstellen aufgrund der UID\-Wiederbenutzung geschützt sind (siehe unten)\&. Falls diese Option aktiviert ist, sollte aufgepasst werden, dass die Prozesse der Unit keinen Zugriff auf Verzeichnisse außerhalb dieser explizit konfigurierten und verwalteten bekommen\&. Verwenden Sie inbesondere nicht \fIBindPaths=\fP und seien Sie vorsichtig mit der Übergabe von \fBAF_UNIX\fP\-Dateideskriptoren für Verzeichnisdateideskriptoren, da dieses Prozessen erlauben würde, Dateien oder Verzeichnisse zu erstellen, die dem dynamischen Benutzer/der dynamischen Gruppe gehören und nicht dem Lebenszyklus und den Zugriffsgarantien des Dienstes unterliegen\&. Standardmäßig »off«\&. .RE .PP \fISupplementaryGroups=\fP .RS 4 Setzt die zusätzlichen Gruppen, unter denen die Prozesse ausgeführt werden\&. Dies akzeptiert eine Leerzeichen\-getrennte Liste von Gruppennamen oder \-Kennungen\&. Diese Option kann mehr als einmal angegeben werden, dann werden alle aufgeführten Gruppen als zusätzliche Gruppen gesetzt\&. Wird die leere Zeichenkette zugewiesen, dann wird die Liste der zusätzlichen Gruppen zurückgesetzt und alle Zuweisungen davor werden unwirksam\&. Auf jeden Fall setzt diese Option nicht die Liste der in der Systemgruppendatenbank für den Benutzer konfigurierten zusätzlichen Gruppen außer Kraft sondern erweitert sie\&. Dies betrifft nicht Befehle, denen »+« vorangestellt ist\&. .RE .PP \fIPAMName=\fP .RS 4 Setzt den PAM\-Dienstenamen, um darunter eine Sitzung einzurichten\&. Falls gesetzt, wird der ausgeführte Prozess als eine PAM\-Sitzung unter dem festgelegten Dienstenamen registriert\&. Dies ist nur in Zusammenspiel mit der Einstellung \fIUser=\fP nützlich und wird sonst ignoriert\&. Falls nicht gesetzt, wird keine PAM\-Sitzung für den ausgeführten Prozess eröffnet\&. Siehe \fBpam\fP(8) für Details\&. .sp Beachten Sie, dass für jede Unit, die diese Option einsetzt, ein PAM\-Sitzungshandhabungsprozess als Teil der Unit verwaltet und aktiv gehalten wird, solange die Unit aktiv ist, um sicherzustellen, dass geeignete Aktionen unternommen werden können, wenn die Unit und damit die PAM\-Sitzung beendet wird\&. Dieser Prozess heißt »(sd\-pam)« und ist ein direkter Kindprozess des Hauptprozesses der Unit\&. .sp Beachten Sie, dass es sehr wahrscheinlich ist (abhängig von der PAM\-Konfiguration), dass der Haupt\-Unit\-Prozess in seine eigene Sitzungsgeltungsbereich\-Unit migriert wird, wenn diese Option für eine Unit verwandt und sie aktiviert wird\&. Dieser Prozess wird daher zwei Units zugeordnet sein: der Unit, in der er ursprünglich gestartet wurde (und für die \fIPAMName=\fP konfiguriert wurde) und der Sitzungsgeltungsbereichs\-Unit\&. Jeder Kindprozess dieses Prozesses wird allerdings nur der Sitzungsgeltungsbereichs\-Unit zugeordnet sein\&. Dies hat Auswirkungen, wenn das in Kombination mit \fINotifyAccess=\fP\fBall\fP verwandt wird, da diese Kindprozesse nicht in der Lage sein werden, Änderungen an der usprünglichen Unit über Benachrichtigungsmeldungen zu erreichen\&. Es wird angenommen, dass diese Nachrichten zu der Sitzungsgeltungsbereichs\-Unit und nicht der ursprünglichen Unit gehören\&. Es wird daher nicht empfohlen, \fIPAMName=\fP in Kombination mit \fINotifyAccess=\fP\fBall\fP zu verwenden\&. .RE .SH CAPABILITIES .PP Diese Optionen sind nur für Systemdienste verfügbar und werden nicht für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstützt\&. .PP \fICapabilityBoundingSet=\fP .RS 4 Steuert, welche Capabilities in der Capability\-Begrenzungsmenge für den ausgeführten Prozess aufgenommen werden\&. Siehe \fBcapabilities\fP(7) für Details\&. Akzeptiert eine Leerzeichen\-getrennte Liste von Capability\-Namen, z\&.B\&. \fBCAP_SYS_ADMIN\fP, \fBCAP_DAC_OVERRIDE\fP, \fBCAP_SYS_PTRACE\fP\&. Aufgeführte Capabilities werden in die Begrenzungsmenge aufgenommen, alle anderen werden entfernt\&. Falls der Liste von Capabilities »~« vorangestellt wird, werden alle bis auf die aufgeführten Capabilities aufgenommen, die Wirkung der Zuweisung invertiert\&. Beachten Sie, dass diese Option auch die respektiven Capabilities in der effektiven, erlaubten und vererbbaren Capability\-Menge betrifft\&. Falls diese Option nicht verwandt wird, wird die Capability\-Begrenzungsmenge bei der Prozessausführung nicht verändert, daher werden keine Begrenzungen bezüglich der Capabilities des Prozesses erzwungen\&. Diese Option kann mehr als einmal auftauchen, die Begrenzungsmengen werden mit \fBODER\fP zusammengeführt oder mit \fBUND\fP, falls den Zeilen »~« vorangestellt wird (siehe unten)\&. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Begrenzungsmenge auf die leere Capability\-Menge zurückgesetzt und alle vorhergehenden Einstellungen haben keine Wirkung\&. Falls auf »~« (ohne weiteres Argument) gesetzt, wird die Begrenzungsmenge auf die komplette Menge der verfügbaren Capabilities zurückgesetzt und alle vorhergehenden Einstellungen zurückgenommen\&. Dies betrifft nicht Befehle, denen »+« vorangestellt wurde\&. .sp Verwenden Sie den Befehl \fBcapability\fP von \fBsystemd\-analyze\fP(1), um eine Liste von Capabilities abzufragen, die auf dem lokalen System definiert sind\&. .sp Beispiel: Falls eine Unit die Einstellunng .sp .if n \{\ .RS 4 .\} .nf CapabilityBoundingSet=CAP_A CAP_B CapabilityBoundingSet=CAP_B CAP_C .fi .if n \{\ .RE .\} .sp hat, dann werden \fBCAP_A\fP, \fBCAP_B\fP und \fBCAP_C\fP gesetzt\&. Falls der zweiten Zeile »~« vorangestellt wird, d\&.h\&. .sp .if n \{\ .RS 4 .\} .nf CapabilityBoundingSet=CAP_A CAP_B CapabilityBoundingSet=~CAP_B CAP_C .fi .if n \{\ .RE .\} .sp dann wird nur \fBCAP_A\fP gesetzt\&. .RE .PP \fIAmbientCapabilities=\fP .RS 4 Steuert, welche Capabilities in der Umgebungs\-Capability\-Menge für den ausgeführten Prozess aufgenommen werden\&. Akzeptiert eine Leerzeichen\-getrennte Liste von Capability\-Namen, z\&.B\&. \fBCAP_SYS_ADMIN\fP, \fBCAP_DAC_OVERRIDE\fP, \fBCAP_SYS_PTRACE\fP\&. Diese Option kann mehr als einmal auftauchen, die Umgebungsmengen werden zusammengeführt (siehe Beispiele oben in \fICapabilityBoundingSet=\fP)\&. Falls der Liste von Capabilities »~« vorangestellt wird, werden alle bis auf die aufgeführten Capabilities aufgenommen, die Wirkung der Zuweisung invertiert\&. Falls die leere Zeichenkette dieser Option zugewiesen wird, wird die Umgebungsmenge auf die leere Capability\-Menge zurückgesetzt und alle vorhergehenden Einstellungen haben keine Wirkung\&. Falls auf »~« (ohne weiteres Argument) gesetzt, wird die Umgebungsmenge auf die komplette Menge der verfügbaren Capabilities zurückgesetzt und alle vorhergehenden Einstellungen zurückgenommen\&. Beachten Sie, dass die Hinzunahme von Capabilities in die Umgebungsmenge sie auch zu der vererbbaren Menge des Prozesses hinzufügt\&. .sp Umgebungs\-Capabilitymengen sind nützlich, falls Sie einen Prozess als nicht privilegierter Benutzer ausführen wollen, ihm aber dennoch einige Capabilities geben möchten\&. Beachten Sie, dass in diesem Fall die Option \fBkeep\-caps\fP automatisch zu \fISecureBits=\fP hinzugefügt wird, um die Capabilities über den Benutzerwechsel hinweg zu erhalten\&. \fIAmbientCapabilities=\fP betrifft keine Befehle, denen »+« vorangestellt ist\&. .RE .SH SICHERHEIT .PP \fINoNewPrivileges=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls wahr, wird sichergestellt, dass der Diensteprozess und sämtliche seiner Kindprozesse niemals mittels \fBexecve()\fP neue Privilegien erlangen können (z\&.B\&. mittels Setuid\- oder Setgid\-Bits oder Dateisystem\-Capabilities)\&. Dies ist die einfachste und effektivste Art, sicherzustellen, dass ein Prozess und seine Kinder niemals wieder Privilegien erhöhen können\&. Standardmäßig falsch, aber bestimmte Einstellungen setzen dies außer Kraft und ignorieren den Wert dieser Einstellung\&. Dies ist der Fall, wenn \fISystemCallFilter=\fP, \fISystemCallArchitectures=\fP, \fIRestrictAddressFamilies=\fP, \fIRestrictNamespaces=\fP, \fIPrivateDevices=\fP, \fIProtectKernelTunables=\fP, \fIProtectKernelModules=\fP, \fIProtectKernelLogs=\fP, \fIProtectClock=\fP, \fIMemoryDenyWriteExecute=\fP, \fIRestrictRealtime=\fP, \fIRestrictSUIDSGID=\fP, \fIDynamicUser=\fP oder \fILockPersonality=\fP festgelegt werden\&. Beachten Sie, dass selbst diese Einstellung durch sie außer Kraft gesetzt wird, \fBsystemctl show\fP zeigt den ursprünglichen Wert dieser Einstellung\&. Siehe auch \m[blue]\fBSchalter »Keine neuen Privilegien«\fP\m[]\&\s-2\u[4]\d\s+2\&. .RE .PP \fISecureBits=\fP .RS 4 Steuert die Menge der sicheren Bits für den ausgeführten Prozess\&. Akzeptiert eine durch Leerzeichen getrennte Kombination von Optionen aus der folgenden Liste: \fBkeep\-caps\fP, \fBkeep\-caps\-locked\fP, \fBno\-setuid\-fixup\fP, \fBno\-setuid\-fixup\-locked\fP, \fBnoroot\fP und \fBnoroot\-locked\fP\&. Diese Option darf mehr als einmal auftauchen, dann werden die sicheren Bits ODER\-verknüpft\&. Falls der Option die leere Zeichenkette zugewiesen wird, werden die Bits auf 0 zurückgesetzt\&. Dies betrift keine Befehle, denen »+« vorangestellt ist\&. Siehe \fBcapabilities\fP(7) für Details\&. .RE .SH "MANDATORY ACCESS CONTROL (VERFPLICHTENDE ZUGRIFFSSTEUERUNG)" .PP Diese Optionen sind nur für Systemdienste verfügbar und werden nicht für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstützt\&. .PP \fISELinuxContext=\fP .RS 4 Setzt den SELinux\-Sicherheitskontext des ausgeführten Prozesses\&. Falls gesetzt, wird dies den automatischen Domain\-Übergang außer Kraft setzen\&. Allerdings muss die Policy den Übergang erlauben\&. Diese Anweisung wird ignoriert, falls SELinux deaktiviert ist\&. Falls »\-« vorangestellt ist, werden alle Fehler ignoriert\&. Dies betrifft keine Befehle, denen »+« vorangestellt ist\&. Siehe \fBsetexeccon\fP(3) für Details\&. .RE .PP \fIAppArmorProfile=\fP .RS 4 Akzeptiert einen Profilnamen als Argument\&. Der von der Unit ausgeführte Prozess wird beim Start in dieses Profil umschalten\&. Profile müssen bereits in den Kernel geladen sein oder die Unit schlägt fehl\&. Falls ein »\-« vorangestellt ist, werden alle Fehler ignoriert\&. Diese Einstellung hat keine Auswirkung, falls AppArmor nicht aktiviert ist\&. Diese Einstellung betrifft keine Befehle, denen »+« vorangestellt ist\&. .RE .PP \fISmackProcessLabel=\fP .RS 4 Akzeptiert ein \fBSMACK64\fP\-Sicherheits\-Label als Argument\&. Der durch diese Unit ausgeführte Prozess wird unter diesem Label gestartet und SMACK wird darauf basierend entscheiden, ob die Ausführung des Prozesses erlaubt ist\&. Der Prozess wird weiter unter dem hier angegebenen Label laufen, außer falls das Programm seinen eigenen \fBSMACK64EXEC\fP\-Label hat, in welchem Falle der Prozess dazu übergehen wird, unter diesem Label zu laufen\&. Falls nicht angegeben, wird der Label verwandt, unter dem Systemd läuft\&. Diese Anweisung wird ignoriert, falls SMACK deaktiviert ist\&. .sp Diesem Wert kann »\-« vorangestellt werden, wodurch alle Fehler ignoriert werden\&. Ein leerer Wert kann angegeben werden, um alle vorhergehenden Zuweisungen zurückzusetzen\&. Dies betrifft keine Befehle, denen »+« vorangestellt ist\&. .RE .SH PROZESSEIGENSCHAFTEN .PP \fILimitCPU=\fP, \fILimitFSIZE=\fP, \fILimitDATA=\fP, \fILimitSTACK=\fP, \fILimitCORE=\fP, \fILimitRSS=\fP, \fILimitNOFILE=\fP, \fILimitAS=\fP, \fILimitNPROC=\fP, \fILimitMEMLOCK=\fP, \fILimitLOCKS=\fP, \fILimitSIGPENDING=\fP, \fILimitMSGQUEUE=\fP, \fILimitNICE=\fP, \fILimitRTPRIO=\fP, \fILimitRTTIME=\fP .RS 4 Setzt die weichen und harten Beschränkungen für verschiedene Ressourcen für ausgeführte Prozesse\&. Siehe \fBsetrlimit\fP(2) für Details über das Ressourcenbegrenzungskonzept\&. Ressourcenbegrenzungen können in zwei Formaten festgelegt werden: entweder als einzelner Wert, um eine bestimmte weiche und harte Begrenzung auf den gleichen Wert zu setzen, oder als Doppelpunkt\-getrenntes Paar \fBweich:hart\fP, um beide Begrenzungen individuell zu setzen (z\&.B\&. »LimitAS=4G:16G«)\&. Verwenden Sie die Zeichenkette \fBinfinity\fP, um keine Begrenzung für eine bestimmte Ressource zu konfigurieren\&. Die multiplikativen Endungen K, M, G, T, P und E (auf Basis 1024) können für Ressourcenbegrenzungen, die in Bytes gemessen werden, verwandt werden (z\&.B\&. »LimitAS=16G«)\&. Für Begrenzungen, die sich auf Zeitwerte beziehen, können die im Englischen normalen Zeiteinheiten ms, s, min, h und so weiter verwandt werden (siehe \fBsystemd.time\fP(7) für Details)\&. Beachten Sie, dass die Standardzeiteinheit als Sekunden impliziert ist, falls keine Zeiteinheit für \fILimitCPU=\fP angegeben ist\&. Für \fILimitRTTIME=\fP wird als Standardeinheit Mikrosekunden impliziert\&. Beachten Sie, dass die effektive Granularität der Begrenzungen ihre Durchsetzung beeinflussen könnte\&. Beispielsweise werden für \fILimitCPU=\fP festgelegte Zeitbeschränkungen implizit auf Vielfache von 1s aufgerundet\&. Für \fILimitNICE=\fP kann der Wert in zwei Syntaxen festgelegt werden: falls ihm »+« oder »\-« vorangestellt wird, wird der Wert als regulärer Linux\-Nice\-Wert im Bereich \-20\&.\&.19 interpretiert\&. Falls ihm so etwas nicht vorangestellt wird, wird der Wert als roher Ressourcenbegrenzungsparameter im Bereich 0\&.\&.40 (wobei 0 äquivalent zu 1 ist) verstanden\&. .sp Beachten Sie, dass die meisten der mit diesen Optionen konfigurierten Ressourcenbeschränkungen prozessbezogen sind\&. 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 \fILimitRSS=\fP unter Linux nicht implementiert ist und das Setzen keinen Effekt hat\&. Oft ist es ratsam, die in \fBsystemd.resource\-control\fP(5) aufgeführten Ressourcensteuerungen gegenüber den prozessabhängigen zu bevorzugen, da sie, auf Dienste als ganzes angewandt, zur Laufzeit verändert werden und im Allgemeinen ausdrucksstärker sind\&. Beispielsweise ist \fIMemoryMax=\fP ein leistungsfähigerer (und funktionierender) Ersatz für \fILimitRSS=\fP\&. .sp Nicht explizit konfigurierte Ressourcenbeschränkungen für eine Unit verwenden als Vorgabe die in den verschiedenen in \fBsystemd\-system.conf\fP(5) verfügbaren Optionen \fIDefaultLimitCPU=\fP, \fIDefaultLimitFSIZE=\fP, … konfigurierten Werte und \(en falls sie dort nicht konfiguriert sind \(en die Kernel\- oder benutzerbezogenen Vorgaben, wie sie durch das Betriebssystem (Letzteres nur für Benutzerdienste, siehe unten) definiert sind\&. .sp 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\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&2.\ \&Ressourcenbegrenzungsanweisungen, ihre äquivalenten Ulimit\-Shell\-Befehle und die verwandte Einheit\fP .TS allbox tab(:); lB lB lB. T{ Anweisung T}:T{ \fBulimit\fP\-Äquivalent T}:T{ Einheit T} .T& l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l. T{ LimitCPU= T}:T{ ulimit \-t T}:T{ Sekunden T} T{ LimitFSIZE= T}:T{ ulimit \-f T}:T{ Bytes T} T{ LimitDATA= T}:T{ ulimit \-d T}:T{ Bytes T} T{ LimitSTACK= T}:T{ ulimit \-s T}:T{ Bytes T} T{ LimitCORE= T}:T{ ulimit \-c T}:T{ Bytes T} T{ LimitRSS= T}:T{ ulimit \-m T}:T{ Bytes T} T{ LimitNOFILE= T}:T{ ulimit \-n T}:T{ Anzahl an Dateideskriptoren T} T{ LimitAS= T}:T{ ulimit \-v T}:T{ Bytes T} T{ LimitNPROC= T}:T{ ulimit \-u T}:T{ Anzahl an Prozessen T} T{ LimitMEMLOCK= T}:T{ ulimit \-l T}:T{ Bytes T} T{ LimitLOCKS= T}:T{ ulimit \-x T}:T{ Anzahl an Sperren T} T{ LimitSIGPENDING= T}:T{ ulimit \-i T}:T{ Anzahl von Signalen in der Warteschlange T} T{ LimitMSGQUEUE= T}:T{ ulimit \-q T}:T{ Bytes T} T{ LimitNICE= T}:T{ ulimit \-e T}:T{ Nice\-Stufe T} T{ LimitRTPRIO= T}:T{ ulimit \-r T}:T{ Echtzeitpriorität T} T{ LimitRTTIME= T}:T{ Kein Äquivalent T}:T{ Mikrosekunden T} .TE .sp 1 .RE .PP \fIUMask=\fP .RS 4 Steuert die Dateimoduserstellungsmaske\&. Akzeptiert einen Zugriffsmodus in oktaler Notation\&. Siehe \fBumask\fP(2) für Details\&. Standardmäßig 0022 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 \(em 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 \fIUMask=\fP in der Systemdiensteinstanz user@\&.service des Benutzers setzen\&. Die benutzerbezogene Umask kann auch mittels des Feldes \fIumask\fP in dem \m[blue]\fBJSON\-Benutzerdatensatz\fP\m[]\&\s-2\u[5]\d\s+2 eines Benutzers gesetzt werden (für Benutzer, die mittels \fBsystemd\-homed.service\fP(8) verwaltet werden, kann dieses Feld auch über \fBhomectl \-\-umask=\fP gesteuert werden)\&. Es kann auch mittels eines PAM\-Moduls wie \fBpam_umask\fP(8) gesetzt werden\&. .RE .PP \fICoredumpFilter=\fP .RS 4 Steuert, welche Arten von Speicher\-Mappings gesichert werden, falls der Prozess einen Speicherauszug durchführt (mittels der Datei /proc/\fIPID\fP/coredump_filter)\&. Akzeptiert eine Leerraum\-getrennte Kombination von Mapping\-Typnamen oder \-nummern (mit der Vorgabebasis 16)\&. Mapping\-Typ\-Namen sind \fBprivate\-anonymous\fP, \fBshared\-anonymous\fP, \fBprivate\-file\-backed\fP, \fBshared\-file\-backed\fP, \fBelf\-headers\fP, \fBprivate\-huge\fP, \fBshared\-huge\fP, \fBprivate\-dax\fP, \fBshared\-dax\fP und der besondere Wert \fBall\fP (alle Typen) und \fBdefault\fP (die Vorgabe des Kernels »\fBprivate\-anonymous\fP \fBshared\-anonymous\fP \fBelf\-headers\fP \fBprivate\-huge\fP«)\&. Siehe \fBcore\fP(5) 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\&. .PP \fBBeispiel\ \&1.\ \&DAX\-Seiten zum Speicherauszugsfilter hinzufügen\fP .sp .if n \{\ .RS 4 .\} .nf CoredumpFilter=default private\-dax shared\-dax .fi .if n \{\ .RE .\} .RE .PP \fIKeyringMode=\fP .RS 4 Steuert, wie der Kernelsitzungsschlüsselbund für den Dienst eingerichtet wird (siehe \fBsession\-keyring\fP(7) für Details über den Sitzungsschlüsselbund)\&. Akzeptiert einen aus \fBinherit\fP, \fBprivate\fP, \fBshared\fP\&. Falls auf \fBinherit\fP gesetzt, wird keine besondere Schlüsselbundeinrichtung vorgenommen und das Standardverhalten des Kernels wird angewandt\&. Falls \fBprivate\fP verwandt wird, wird ein neuer Sitzungsschlüsselbund bereitgestellt, wenn ein Diensteprozess aufgerufen wird und dieser nicht mit einem Benutzerschlüsselbund verbunden ist\&. Dies ist die für Systemdienste empfohlene Einstellung, da sie sicherstellt, dass mehrere Dienste, die unter der gleichen Systembenutzerkennung laufen (insbesondere des Benutzers root) ihr Schlüsselmaterial nicht gemeinsam benutzen\&. Falls \fBshared\fP verwandt wird, wird ein neuer Schlüsselbund wie für \fBprivate\fP reserviert, aber der Benutzerschlüsselbund des mit \fIUser=\fP konfigurierten Benutzers wird mit 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 \fBinherit\fP wird die eindeutige Aufrufkennung für die Unit (siehe unten) als geschützter Schlüssel unter dem Namen »invocation_id« zu dem neu erstellten Sitzungsschlüsselbund hinzugefügt\&. Standardmäßig \fBprivate\fP für Dienste des Systemdiensteverwalters und \fBinherit\fP für nicht Dienste\-Units und für Dienste des Benutzerdiensteverwalters\&. .RE .PP \fIOOMScoreAdjust=\fP .RS 4 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 \m[blue]\fBproc\&.txt\fP\m[]\&\s-2\u[6]\d\s+2 für Details\&. Falls nicht angegeben, ist die Vorgabe die OOM\-Bewertungsanpassungsstufe des Diensteverwalters selbst, die normalerweise auf 0 gesetzt ist\&. .sp Verwenden Sie die Einstellung \fIOOMPolicy=\fP von Dienste\-Units, um zu konfigurieren, wie der Diensteverwalter darauf reagieren soll, wenn der OOM\-Killer einen Prozess des Dienstes beendet\&. Siehe \fBsystemd.service\fP(5) für Details\&. .RE .PP \fITimerSlackNSec=\fP .RS 4 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 \fBprctl\fP(2) für weitere Informationen\&. Beachten Sie, dass im Gegensatz zu den meisten anderen Zeitdauerdefinitionen dieser Parameter einen Ganzzahlwert in Nanosekunden akzeptiert, falls keine Einheit angegeben ist\&. Es werden auch die normalen Zeiteinheiten verstanden\&. .RE .PP \fIPersonality=\fP .RS 4 Steuert, welche Kernelarchitektur \fBuname\fP(2) melden soll, wenn es von Unit\-Prozessen aufgerufen wird\&. Akzeptiert eine der Architekturkennungen \fBx86\fP, \fBx86\-64\fP, \fBppc\fP, \fBppc\-le\fP, \fBppc64\fP, \fBppc64\-le\fP, \fBs390\fP oder \fBs390x\fP\&. Welche Personalitätsarchitekturen unterstützt werden, hängt von der Systemarchitektur ab\&. Normalerweise unterstützen die 64\-Bit\-Versionen der verschiedenen Systemarchitekturen die direkte Entsprechung der 32\-Bit\-Personalitätsarchitektur, aber keine anderen\&. Beispielsweise unterstützen \fBx86\-64\fP\-Systeme die \fBx86\-64\fP\- und \fBx86\fP\-Personalitäten, aber keine anderen\&. Die Personalitätsfunktionalität ist nützlich, wenn 32\-Bit\-Dienste auf einem 64\-Bit\-System ausgeführt werden\&. Falls nicht angegeben, wird die Personalität nicht verändert und spiegelt daher die Personalität des Systemkernels wider\&. .RE .PP \fIIgnoreSIGPIPE=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls wahr, wird \fBSIGPIPE\fP in dem ausgeführten Prozess ignoriert\&. Standardmäßig wahr, da \fBSIGPIPE\fP im Allgemeinen nur in Shell\-Pipes nützlich ist\&. .RE .SH SCHEDULING .PP \fINice=\fP .RS 4 Setzt den Vorgabe\-Nice\-Wert (Scheduling\-Priorität) für ausgeführte Prozesse\&. Akzeptiert eine Ganzzahl zwischen \-20 (höchste Priorität) und 19 (niedrigste Priorität)\&. Siehe \fBsetpriority\fP(2) für Details\&. .RE .PP \fICPUSchedulingPolicy=\fP .RS 4 Setzt die CPU\-Scheduling\-Richtlinie für ausgeführte Prozesse\&. Akzeptiert eines aus \fBother\fP, \fBbatch\fP, \fBidle\fP, \fBfifo\fP, \fBrr\fP\&. Siehe \fBsched_setscheduler\fP(2) für Details\&. .RE .PP \fICPUSchedulingPriority=\fP .RS 4 Setzt die CPU\-Scheduling\-Priorität für ausgeführte Prozesse\&. Der verfügbare Prioritätenbereich hängt von der ausgewählten CPU\-Scheduling\-Richtlinie (siehe oben) ab\&. Für Echtzeit\-Scheduling\-Richtlinien kann eine Ganzzahl zwischen 1 (niedrigste Priorität) und 99 (höchste Priorität) verwandt werden\&. Siehe \fBsched_setscheduler\fP(2) für Details\&. .RE .PP \fICPUSchedulingResetOnFork=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls wahr, werden erhöhte CPU\-Scheduling\-Prioritäten und \-Richtlinien zurückgesetzt, wenn ausgeführte Prozesse \fBfork\fP(2) aufrufen und können daher nicht an Kindprozesse durchsickern\&. Siehe \fBsched_setscheduler\fP(2) für Details\&. Standardmäßig falsch\&. .RE .PP \fICPUAffinity=\fP .RS 4 Steuert die CPU\-Affinität des ausgeführten Prozesses\&. Akzeptiert eine durch Leerraum oder Kommata getrennte Liste von CPU\-Indizes oder \-Bereichen\&. Alternativ wird der besondere Wert »numa« akzeptiert\&. In diesem Fall leitet Systemd die erlaubten CPU\-Bereiche basierend auf der Option \fINUMAMask=\fP automatisch ab\&. CPU\-Bereiche werden durch den unteren und oberen CPU\-Index, getrennt durch einen Bindestrich, festgelegt\&. Diese Option kann mehr als einmal angegeben werden; in diesem Fall werden die festgelegten CPU\-Affinitätsmasken zusammengeführt\&. Falls die leere Zeichenkette zugewiesen wird, wird die Maske zurückgesetzt und alle vorherigen Zuweisungen haben keinen Effekt\&. Siehe \fBsched_setaffinity\fP(2) für Details\&. .RE .PP \fINUMAPolicy=\fP .RS 4 Steuert die NUMA\-Speicherrichtlinie des ausgeführten Prozesses\&. Akzeptiert einen Richtlinientyp, einer aus: \fBdefault\fP, \fBpreferred\fP, \fBbind\fP, \fBinterleave\fP und \fBlocal\fP\&. Eine Liste von NUMA\-Knoten, die der Richtlinie zugeordnet werden sollen, muss in \fINUMAMask=\fP festgelegt werden\&. Für weitere Details über jede Richtlinie lesen Sie bitte \fBset_mempolicy\fP(2)\&. Für einen allgemeinen Überblick über die NUMA\-Unterstützung in Linux, siehe \fBnuma\fP(7)\&. .RE .PP \fINUMAMask=\fP .RS 4 Steuert die NUMA\-Knotenliste, die zusammen mit der ausgewählten NUMA\-Richtlinie angewandt wird\&. Akzeptiert eine Liste von NUMA\-Knoten und hat die gleiche Syntax wie eine Liste von CPUs für die Option \fICPUAffinity=\fP oder den besonderen Wert »all«, der alle verfügbaren NUMA\-Knoten in der Maske enthält\&. Beachten Sie, dass für die Richtlinien \fBdefault\fP und \fBlocal\fP keine Liste von NUMA\-Knoten benötigt und für die Richtlinie \fBpreferred\fP ein einzelner NUMA\-Knoten erwartet wird\&. .RE .PP \fIIOSchedulingClass=\fP .RS 4 Setzt die E/A\-Scheduling\-Klasse für ausgeführte Prozesse\&. Akzeptiert eine Ganzzahl zwischen 0 und 3 oder eine der Zeichenketten \fBnone\fP, \fBrealtime\fP, \fBbest\-effort\fP oder \fBidle\fP\&. Falls dieser Option die leere Zeichenkette zugewiesen wird, haben alle vorhergehenden Zuweisungen zu \fIIOSchedulingClass=\fP und \fIIOSchedulingPriority=\fP keinen Effekt\&. Siehe \fBioprio_set\fP(2) für Details\&. .RE .PP \fIIOSchedulingPriority=\fP .RS 4 Setzt die E/A\-Scheduling\-Priorität für ausgeführte Prozesse\&. Akzeptiert eine Ganzzahl zwischen 0 (höchste Priorität) und 7 (niedrigste Priorität)\&. Die verfügbaren Prioritäten hängen von der ausgewählten E/A\-Scheduling\-Klasse (siehe oben) ab\&. Falls dieser Option die leere Zeichenkette zugewiesen wird, haben alle vorhergehenden Zuweisungen zu \fIIOSchedulingClass=\fP und \fIIOSchedulingPriority=\fP keinen Effekt\&. Siehe \fBioprio_set\fP(2) für Details\&. .RE .SH SANDBOXING .PP Die nachfolgenden Sandboxing\-Optionen bieten eine wirksame Art, die Kontakte des 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 \fIProtectSystem=\fP keine Wirkung, falls der Kernel ohne Namensräume für Dateisysteme gebaut wurde oder falls der Diensteverwalter in einem Container\-Verwalter ausgeführt wird, der dafür sorgt, dass Dateisystem\-Namensräume für seine Nutzlast nicht verfügbar sind\&. Ähnlich hat \fIRestrictRealtime=\fP auf Systemen keine Wirkung, denen die Unterstützung für SECCOMP\-Systemaufruffilterung fehlt oder in Containern, in denen die Unterstützung dafür abgeschaltet ist\&. .PP Beachten Sie auch, dass einige Sandboxing\-Funktionalität im Allgemeinen in Benutzerdiensten (d\&.h\&. Diensten, die vom benutzerbezogenen Diensteverwalter ausgeführt werden) nicht verfügbar ist\&. Insbesondere die verschiedenen Einstellungen, die die Unterstützung für Dateisystem\-Namensräume benötigen (wie \fIProtectSystem=\fP) sind nicht verfügbar, da die zugrundeliegende Kernelfunktionalität nur für privilegierte Prozesse erreichbar ist\&. Allerdings werden die meisten Namensraum\-Einstellungen, die nicht in ihrem eigenen Benutzerdienst funktionieren, bei der Verwendung zusammen mit \fIPrivateUsers=\fP\fBtrue\fP funktionieren\&. .PP \fIProtectSystem=\fP .RS 4 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 \fIPrivateDevices=\fP, \fIProtectKernelTunables=\fP, \fIProtectControlGroups=\fP)\&. Diese Einstellung stellt sicher, dass alle Änderungen an dem vom Lieferanten bereitgestellten Betriebssystem (und optional seiner Konfiguration und lokaler Einhängungen) für den Dienst verboten sind\&. Es wird empfohlen, diese Einstellung für alle langlaufenden Dienste zu aktivieren, außer sie sind an Systemaktualisierungen beteiligt oder müssen das Betriebssystem auf eine andere Art verändern\&. Falls diese Option verwandt wird, kann \fIReadWritePaths=\fP verwandt werden, um bestimmte Verzeichnisse von dem nur lesbaren Verhalten auszunehmen\&. Diese Einstellung ist impliziert, falls \fIDynamicUser=\fP gesetzt ist\&. Diese Einstellung kann nicht für alle Fälle den Schutz sicherstellen\&. Im Allgemeinen hat es die gleichen Begrenzungen wie \fIReadOnlyPaths=\fP, siehe unten\&. Standardmäßig aus\&. .RE .PP \fIProtectHome=\fP .RS 4 Akzeptiert ein logisches Argument oder die besonderen Werte »read\-only« oder »tmpfs«\&. Falls wahr, wird der Zugriff auf die Verzeichnisse /home/, /root und /run/user entzogen, sie erscheinen für von der Unit aufgerufene Prozesse leer\&. Falls auf »read\-only« gesetzt, werden die drei Verzeichnisse stattdessen nur lesbar gesetzt\&. Falls auf »tmpfs« gesetzt, werden temporäre Dateisysteme auf diesen drei Verzeichnissen im nur\-lesbaren Modus eingehängt\&. Der Wert »tmpfs« ist nützlich, um Home\-Verzeichnisse, die für die von der Unit aufgerufenen Prozesse nicht relevant sind, zu verstecken, während gleichzeitig notwendige Verzeichnisse weiterhin sichtbar gemacht werden können, indem sie mit \fIBindPaths=\fP oder \fIBindReadOnlyPaths=\fP aufgelistet werden\&. .sp Setzen dieser Einstellung auf »yes« ist fast äquivalent zum Setzen der drei Verzeichnisse in \fIInaccessiblePaths=\fP\&. Ähnlich ist »read\-only« fast äquivalent zu \fIReadOnlyPaths=\fP und »tmpfs« ist fast äquivalent zu \fITemporaryFileSystem=\fP mit »:ro«\&. .sp Es wird empfohlen, diese Einstellung für alle langlaufenden Dienste (insbesondere solchen zu Netzen) zu aktivieren, um sicherzustellen, dass sie keinen Zugriff auf private Benutzerdaten bekommen, außer der Dienst benötigt tatsächlich Zugriff auf die privaten Daten der Benutzer\&. Diese Einstellung ist impliziert, falls \fIDynamicUser=\fP gesetzt ist\&. Diese Einstellung kann nicht für alle Fälle den Schutz sicherstellen\&. Im Allgemeinen hat es die gleichen Begrenzungen wie \fIReadOnlyPaths=\fP, siehe unten\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIRuntimeDirectory=\fP, \fIStateDirectory=\fP, \fICacheDirectory=\fP, \fILogsDirectory=\fP, \fIConfigurationDirectory=\fP .RS 4 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\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&3.\ \&Automatische Verzeichniserstellung und Umgebungsvariablen\fP .TS allbox tab(:); lB lB lB lB. T{ Verzeichnis T}:T{ Unterhalb vom Pfad von System\-Units T}:T{ Unterhalb vom Pfad von Benutzer\-Units T}:T{ Umgebungsvariablenmenge T} .T& l l l l l l l l l l l l l l l l l l l l. T{ \fIRuntimeDirectory=\fP T}:T{ /run/ T}:T{ \fI$XDG_RUNTIME_DIR\fP T}:T{ \fI$RUNTIME_DIRECTORY\fP T} T{ \fIStateDirectory=\fP T}:T{ /var/lib/ T}:T{ \fI$XDG_CONFIG_HOME\fP T}:T{ \fI$STATE_DIRECTORY\fP T} T{ \fICacheDirectory=\fP T}:T{ /var/cache/ T}:T{ \fI$XDG_CACHE_HOME\fP T}:T{ \fI$CACHE_DIRECTORY\fP T} T{ \fILogsDirectory=\fP T}:T{ /var/log/ T}:T{ \fI$XDG_CONFIG_HOME\fP/log/ T}:T{ \fI$LOGS_DIRECTORY\fP T} T{ \fIConfigurationDirectory=\fP T}:T{ /etc/ T}:T{ \fI$XDG_CONFIG_HOME\fP T}:T{ \fI$CONFIGURATION_DIRECTORY\fP T} .TE .sp 1 Im Falle von \fIRuntimeDirectory=\fP werden die innersten Unterverzeichnisse entfernt, wenn die Unit gestoppt wird\&. Es ist möglich, in diesem Fall die festgelegten Verzeichnisse zu erhalten, falls \fIRuntimeDirectoryPreserve=\fP auf \fBrestart\fP oder \fByes\fP konfiguriert ist (siehe unten)\&. Die mit \fIStateDirectory=\fP, \fICacheDirectory=\fP, \fILogsDirectory=\fP, \fIConfigurationDirectory=\fP festgelegten Verzeichnisse werden nicht entfernt, wenn die Unit gestoppt wird\&. .sp Außer im Fall von \fIConfigurationDirectory=\fP werden die innersten festgelegten Verzeichnisse dem in \fIUser=\fP und \fIGroup=\fP 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 \fIRuntimeDirectoryMode=\fP, \fIStateDirectoryMode=\fP, \fICacheDirectoryMode=\fP, \fILogsDirectoryMode=\fP und \fIConfigurationDirectoryMode=\fP festgelegt ist, angepasst\&. .sp Diese Optionen implizieren \fIBindPaths=\fP für die festgelegten Pfade\&. Bei der Kombination mit \fIRootDirectory=\fP oder \fIRootImage=\fP werden diese Pfade immer innerhalb des Rechners liegen und von dort in den Dateisystemnamensraum der Unit eingehängt\&. .sp Falls \fIDynamicUser=\fP zusammen mit \fIStateDirectory=\fP verwandt wird, ändert sich die Logik für \fICacheDirectory=\fP und \fILogsDirectory=\fP leicht: die Verzeichnisse werden unterhalb /var/lib/private, /var/cache/private bzw\&. /var/log/private erstellt, die Verzeichnisse des Rechners sind, die für nicht privilegierte Benutzer nicht zugreifbar sind\&. Dadurch wird sichergestellt, dass Zugriff auf diese Verzeichnisse nicht über die Wiederverwendung dynamischer Benutzerkennungen möglich ist\&. Symbolische Links werden erstellt, um diese Unterschiede im Verhalten zu verstecken\&. Daher tauchen sowohl aus Sicht des Rechners als auch aus innerhalb der Unit die relevanten Verzeichnisse immer direkt unter /var/lib, /var/cache und /var/log auf\&. .sp Verwenden Sie \fIRuntimeDirectory=\fP, um eine oder mehrere Laufzeitverzeichnisse für die Unit zu verwalten und ihre Lebensdauer an die Lebensdauer des Daemons zu koppeln\&. Dies ist insbesonders für nicht privilegierte Daemons nützlich, die aufgrund fehlender Privilegien keine Laufzeitverzeichnisse in /run/ erstellen können und um sicherzustellen, dass die Laufzeitverzeichnisse nach der Verwendung automatisch bereinigt werden\&. Für Laufzeitverzeichnisse, die eine komplexere oder andere Konfiguration oder Lebensdauergarantie benötigen, prüfen Sie den Einsatz von \fBtmpfiles.d\fP(5)\&. .sp 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\&. .sp \fBtmpfiles.d\fP(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\&. .sp Um alle von diesen Einstellungen erzeugten Verzeichnisse zu entfernen, verwenden Sie den Befehl \fBsystemctl clean …\fP auf die relevanten Units, siehe \fBsystemctl\fP(1) für Details\&. .sp Beispiel: Falls eine Systemdienste\-Unit .sp .if n \{\ .RS 4 .\} .nf RuntimeDirectory=foo/bar baz .fi .if n \{\ .RE .\} .sp enthält, erstellt der Diensteverwalter /run/foo (falls es noch nicht existiert), /run/foo/bar und /run/baz\&. Die Verzeichnisse /run/foo/bar und /run/baz außer /run/foo gehören dem Benutzer und der Gruppe, die in \fIUser=\fP und \fIGroup=\fP angegeben sind und werden entfernt, wenn der Dienst gestoppt wird\&. .sp Beispiel: Falls eine Systemdienste\-Unit .sp .if n \{\ .RS 4 .\} .nf RuntimeDirectory=foo/bar StateDirectory=aaa/bbb ccc .fi .if n \{\ .RE .\} .sp enthält, dann wird die Umgebungsvariable »RUNTIME_DIRECTORY« mit »/run/foo/bar« und »STATE_DIRECTORY« mit »/var/lib/aaa/bbb:/var/lib/ccc« gesetzt\&. .RE .PP \fIRuntimeDirectoryMode=\fP, \fIStateDirectoryMode=\fP, \fICacheDirectoryMode=\fP, \fILogsDirectoryMode=\fP, \fIConfigurationDirectoryMode=\fP .RS 4 Legt die Zugriffsmodi der in \fIRuntimeDirectory=\fP, \fIStateDirectory=\fP, \fICacheDirectory=\fP, \fILogsDirectory=\fP bzw\&. \fIConfigurationDirectory=\fP angegebenen Verzeichnisse in einer oktalen Zahl fest\&. Standardmäßig \fB0755\fP\&. Siehe »Permissions« in \fBpath_resolution\fP(7) für eine Diskussion über die Benennung der Berechtigungs\-Bits\&. .RE .PP \fIRuntimeDirectoryPreserve=\fP .RS 4 Akzeptiert ein logisches Argument oder \fBrestart\fP\&. Falls auf die Vorgabe \fBno\fP gesetzt, werden die in \fIRuntimeDirectory=\fP festgelegten Verzeichnisse immer entfernt, wenn der Dienst beendet wird\&. Falls auf \fBrestart\fP gesetzt, werden die Verzeichnisse erhalten, wenn der Dienst sowohl automatisch als auch manuell neu gestartet wird\&. Hier bedeutet der automatische Neustart die in \fIRestart=\fP festgelegte Aktion und manueller Neustart bedeutet die durch \fBsystemctl restart foo\&.service\fP ausgelöste\&. Falls auf \fIyes\fP gesetzt, werden die Verzeichnisse nicht entfernt, wenn der Dienst beendet wird\&. Beachten Sie, dass die in \fIRuntimeDirectory=\fP festgelegten Verzeichnisse entfernt werden, wenn das System neu gestartet wird, da das Laufzeitverzeichnis /run/ ein »tmpfs«\-Einhängepunkt ist\&. .RE .PP \fITimeoutCleanSec=\fP .RS 4 Konfiguriert für die mittels \fBsystemctl clean …\fP erbetene Aufräumaktion eine Zeitüberschreitung, siehe \fBsystemctl\fP(1) für Details\&. Akzeptiert die gewöhnlichen Zeitwerte und ist standardmäßig \fBinfinity\fP, 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\&. .RE .PP \fIReadWritePaths=\fP, \fIReadOnlyPaths=\fP, \fIInaccessiblePaths=\fP .RS 4 Richtet einen neuen Dateisystemnamensraum für ausgeführte Prozesse ein\&. Diese Optionen können zur Begrenzung des Zugriffs eines Prozesses auf 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 \fIRootDirectory=\fP/\fIRootImage=\fP gesetzten Wurzelverzeichnis aufgelöst werden, falls sie Symlinks enthalten\&. .sp In \fIReadWritePaths=\fP aufgeführte Pfade sind von innerhalb des Namensraums mit den gleichen Zugriffsmodi wie von außerhalb zugreifbar\&. Auf in \fIReadOnlyPaths=\fP aufgeführte Pfade kann nur lesend zugegriffen werden, Schreiben wird abgelehnt, selbst falls die normale Dateizugriffssteuerung dies erlauben würde\&. Schachteln Sie \fIReadWritePaths=\fP innerhalb von \fIReadOnlyPaths=\fP, um schreibbare Unterverzeichnisse innerhalb nur lesbarer Verzeichnisse bereitzustellen\&. Verwenden Sie \fIReadWritePaths=\fP, um bestimmte Pfade für den Schreibzugriff freizuschalten, falls \fIProtectSystem=strict\fP verwandt wird\&. .sp In \fIInaccessiblePaths=\fP aufgeführte Pfade, einschließlich der Dateisystemhierarchie darunter, werden für Prozesse innerhalb des Namensraums unzugreifbar gemacht\&. Dies könnte restriktiver als gewünscht sein, da es nicht möglich ist, darin \fIReadWritePaths=\fP, \fIReadOnlyPaths=\fP, \fIBindPaths=\fP oder \fIBindReadOnlyPaths=\fP zu verschachteln\&. Für eine flexiblere Option siehe \fITemporaryFileSystem=\fP\&. .sp Es können auch Pfade, die keine Verzeichnisse sind, angegeben werden\&. Diese Optionen können mehr als einmal angegeben werden, dann haben alle aufgeführten Pfade von innerhalb des Namensraums aus beschränkten Zugriff\&. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste zurückgesetzt und alle vorherigen Zuweisungen haben keinen Effekt\&. .sp Pfaden in \fIReadWritePaths=\fP, \fIReadOnlyPaths=\fP und \fIInaccessiblePaths=\fP kann ein »\-« vorangestellt werden, wodurch sie ignoriert werden, falls sie nicht existieren\&. Falls ihnen »+« vorangestellt wird, werden die Pfade als relativ zum Wurzelverzeichnis der Unit akzeptiert, wie dies mit \fIRootDirectory=\fP/\fIRootImage=\fP konfiguriert ist, statt relativ zum Wurzelverzeichnis des Rechners (siehe oben)\&. Wenn Sie »\-« und »+« auf dem gleichen Pfad kombinieren, verwenden Sie »\-« zuerst und danach »+«\&. .sp Beachten Sie, dass diese Einstellungen die Ausbreitung von Einhängungen von den Prozessen einer Unit zum Rechner abtrennt\&. Dies bedeutet, dass diese Einstellung nicht für Dienste benutzt werden darf, die in der Lage sein müssen, Einhängepunkte im Haupteinhängenamensraum zu installieren\&. Die \fIReadWritePaths=\fP\- und \fIReadOnlyPaths=\fP\-Ausbreitung in die andere Richtung ist nicht betroffen, d\&.h\&. Einhängungen, die im Rechner erstellt werden, tauchen im Allgemeinen im Namensraum der Unit auf und Einhängungen, die auf dem Rechner entfernt werden, verschwinden auch dort\&. Beachten Sie insbesondere, dass die Einhängeausbreitung vom Rechner zu der Unit dazu führt, dass unveränderte Einhängungen im Namensraum der Unit erstellt werden, d\&.h\&. schreibbare Einhängungen, die auf dem Rechner auftauchen, werden auch im Namensraum der Unit schreibbar sein, selbst wenn sie zu einem Pfad ausgebreitet werden, der mit \fIReadOnlyPaths=\fP markiert ist! Daher wird die Zugriffseinschränkung mit diesen Optionen nicht auf Untereinhängungen eines Verzeichnisses, das später erstellt wird, ausgeweitet\&. Dies bedeutet, dass die durch diese Einstellung angebotene Sperrung nicht vollständig ist und keinen vollständigen Schutz bietet\&. .sp Beachten Sie, dass die Wirkung dieser Einstellung durch privilegierte Prozesse zurückgenommen werden kann\&. Um eine wirksame Sandbox\-Umgebung für eine Unit einzurichten, wird daher empfohlen, diese Einstellungen mit entweder \fICapabilityBoundingSet=~CAP_SYS_ADMIN\fP oder \fISystemCallFilter=~@mount\fP zu kombinieren\&. .sp Diese Optionen sind nur für Systemdienste verfügbar und werden nicht für Dienste, die in benutzerbezogenen Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fITemporaryFileSystem=\fP .RS 4 Akzeptiert eine Leerzeichen\-getrennte Liste von Einhängepunkten für temporäre Dateisysteme (tmpfs)\&. Falls gesetzt, wird ein neuer Dateisystemnamensraum für ausgeführte Prozesse eingerichtet und in jeden Einhängepunkt ein temporäres Dateisystem eingehängt\&. Diese Option kann mehr als einmal 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«\&. .sp Dies ist nützlich, um Dateien oder Verzeichnisse, die für die von der Unit gestarteten Prozesse nicht relevant sind, zu verstecken, während auf notwendige Dateien oder Verzeichnisse durch Kombination mit \fIBindPaths=\fP oder \fIBindReadOnlyPaths=\fP weiterhin zugegriffen werden kann: .sp Beispiel: Falls eine Unit die Einstellunng .sp .if n \{\ .RS 4 .\} .nf TemporaryFileSystem=/var:ro BindReadOnlyPaths=/var/lib/systemd .fi .if n \{\ .RE .\} .sp Der durch die Unit aufgerufene Prozess kann dann keine Dateien, Verzeichnisse oder Inhalte unter /var/ außer /var/lib/systemd sehen\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIPrivateTmp=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls wahr, wird ein neuer Dateisystemnamensraum für den ausgeführten Prozess eingerichtet und private /tmp/\- und /var/tmp/\-Verzeichnisse darin eingehängt, die nicht mit Prozessen außerhalb des Namensraums gemeinsam genutzt werden\&. Dies ist nützlich, um Zugriff auf temporäre Dateien des Prozesses abzusichern, allerdings ist die gemeinsame Benutzung von Inhalten über /tmp/ oder /var/tmp/ mit anderen Prozessen unmöglich\&. Falls dies aktiviert ist, werden alle durch einen Dienst in diesen Verzeichnissen erstellten temporären Dateien entfernt, nachdem der Dienst gestoppt ist\&. Standardmäßig falsch\&. Es ist möglich, zwei oder mehr Units mit dem gleichen privaten /tmp/\- und /var/tmp/\-Namensraum durch Verwendung der Anweisung \fIJoinsNamespaceOf=\fP zu benutzen, siehe \fBsystemd.unit\fP(5) für Details\&. Diese Einstellung ist impliziert, falls \fIDynamicUser=\fP gesetzt ist\&. Für diese Einstellung gelten die gleichen Beschränkungen bezüglich Einhängeausbreitung und Privilegien wie für \fIReadOnlyPaths=\fP und verwandte Aufrufe, siehe oben\&. Aktivieren dieser Einstellung hat den Seiteneffekt des Hinzufügens der Abhängigkeiten \fIRequires=\fP und \fIAfter=\fP zu allen für den Zugriff auf /tmp/ und /var/tmp/ notwendigen Einhänge\-Units\&. Desweiteren wird eine implizite \fIAfter=\fP\-Ordnung auf \fBsystemd\-tmpfiles\-setup.service\fP(8) hinzugefügt\&. .sp Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Einhängenamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIPrivateDevices=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls wahr, wird eine neue /dev/\-Einhängung für den ausgeführten Prozess eingerichtet und nur API\-Pseudogeräte wie /dev/null, /dev/zero oder /dev/random (sowie das Pseudo\-TTY\-Untersystem) hinzugefügt, aber keine physischen Geräte wie /dev/sda, Systemspeicher /dev/mem, System\-Ports /dev/port und andere\&. Dies ist nützlich, um Zugriff auf physische Geräte für ausgeführte Prozesse sicher abzustellen\&. Standardmäßig falsch\&. Aktivieren dieser Option wird einen Systemaufruffilter installieren, um systemnahe E/A\-Systemaufrufe, die in der Gruppe \fI@raw\-io\fP versammelt sind, zu blockieren, \fBCAP_MKNOD\fP und \fBCAP_SYS_RAWIO\fP aus der Capability\-Begrenzungsmenge für die Unit (siehe oben) zu entfernen und \fIDevicePolicy=closed\fP zu setzen (siehe \fBsystemd.resource\-control\fP(5) für Details)\&. Beachten Sie, dass die Verwendung dieser Einstellung die Ausbreitung von Einhängungen aus dem Dienst zum Rechner trennen wird (Ausbreitung in die umgekehrte Richtung wird weiterhin funktionieren)\&. Dies bedeutet, dass diese Einstellung nicht für Dienste benutzt werden kann, die in der Lage sein sollen, Einhängepunkte in dem Haupteinhängeraum zu installieren\&. Das neue /dev/ wird nur lesbar und »noexec« eingehängt\&. Letzteres könnte alte Programme beschädigen, die mit \fBmmap\fP(2) aus /dev/zero ausführbaren Speicher einrichten, statt \fBMAP_ANON\fP zu verwenden\&. Für diese Einstellung gelten die gleichen Einschränkungen im Hinblick auf Einhängeausbreitung und Privilegien wie für \fIReadOnlyPaths=\fP und verwandte Aufrufe, siehe oben\&. Falls dies eingeschaltet und im Benutzermodus oder im Systemmodus aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=\fP) betrieben wird, wird \fINoNewPrivileges=yes\fP impliziert\&. .sp Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Einhängenamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIPrivateNetwork=\fP .RS 4 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 \fIJoinsNamespaceOf=\fP zu benutzen, siehe \fBsystemd.unit\fP(5) für Details\&. Beachten Sie, dass diese Option alle Socket\-Einrichtungen, einschließlich \fBAF_NETLINK\fP und \fBAF_UNIX\fP, vom Rechner trennen wird\&. Effektiv bedeutet das für \fBAF_NETLINK\fP, dass von \fBsystemd\-udevd.service\fP(8) empfangene Gerätekonfigurationsereignisse nicht zu den Prozessen der Unit ausgeliefert werden\&. Und für \fBAF_UNIX\fP hat dies den Effekt, dass \fBAF_UNIX\fP\-Sockets in dem abstrakten Namensraum des Rechners für Prozesse der Unit unverfügbar werden (allerdings werden solche im Dateisystem weiterhin zugreifbar sein)\&. .sp Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Netzwerknamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt\&. .sp 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 \fIJoinsNamespaceOf=\fP kombiniert werden, um auf Sockets innerhalb von Netzwerknamensräumen von anderen Diensten auf Anfragen zu warten\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fINetworkNamespacePath=\fP .RS 4 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 \fIPrivateNetwork=\fP keine Wirkung\&. Falls diese Option zusammen mit \fIJoinsNamespaceOf=\fP verwandt wird, dann hat sie nur eine Wirkung, falls diese Unit gestartet wird, bevor alle der aufgeführten Units, die \fIPrivateNetwork=\fP oder \fINetworkNamespacePath=\fP konfiguriert haben, gestartet wird, da andernfalls der Netzwerknamensraum dieser Units neu verwendet wird\&. .sp 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\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIPrivateUsers=\fP .RS 4 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 \fICapabilityBoundingSet=\fP beeinflussen nur Letzteren und es gibt keine Möglichkeit, zusätzliche Capabilities im Benutzerraum des Systems zu erlangen\&. Standardmäßig aus\&. .sp 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 \fIPrivateUsers=\fP\fBtrue\fP mit anderen Namensräumen die Verwendung von Funktionalitäten aktiviert, die normalerweise von benutzerbezogenen Instanzen des Diensteverwalters nicht unterstützt werden\&. .sp Diese Einstellung ist insbesondere im Zusammenspiel mit \fIRootDirectory=\fP/\fIRootImage=\fP nützlich, da die Notwendigkeit, die Benutzer\- und Gruppendatenbank im Wurzelverzeichnis und dem Gesamtsystem zu synchronisieren, reduziert wird, da die einzigen Benutzer und Gruppen, die angepasst werden müssen, »root«, »nobody« und der Benutzer und die Gruppe der Unit selbst sind\&. .sp Beachten Sie, dass die Implementierung dieser Einstellung unmöglich sein könnte (beispielsweise, falls Benutzernamensräume nicht verfügbar sind) und dass die Unit auf eine Art geschrieben sein sollte, die sich nicht ausschließlich auf diese Einstellung für die Sicherheit verlässt\&. .RE .PP \fIProtectHostname=\fP .RS 4 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«\&. .sp 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\&. .sp 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\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIProtectClock=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls wahr, werden Schreibzugriffe auf die Hardware\- oder System\-Uhr verweigert\&. Für die meisten Dienste, die die Uhr nicht verändern müssen, wird empfohlen, dies einzuschalten\&. Standardmäßig aus\&. Aktivierung dieser Option entfernt \fBCAP_SYS_TIME\fP und \fBCAP_WAKE_ALARM\fP aus der Capability\-Begrenzungsmenge für diese Unit, installiert einen Systemaufruffilter, um Systemaufruf zu blockieren, die die Uhr stellen und \fIDeviceAllow=char\-rtc r\fP ist impliziert\&. Dies stellt sicher, dass /dev/rtc0, /dev/rtc1 usw\&. für den Dienst nur lesbar werden\&. Siehe \fBsystemd.resource\-control\fP(5) für die Details von \fIDeviceAllow=\fP\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIProtectKernelTunables=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls wahr, sind die durch /proc/sys/, /sys/, /proc/sysrq\-trigger, /proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs und /proc/irq verfügbaren Kernelvariablen für alle Prozesse der Unit nur lesbar\&. Normalerweise sollten einstellbare Kernelvariablen nur zum Systemstartzeitpunkt initialisiert werden, beispielsweise über den Mechanismus \fBsysctl.d\fP(5)\&. Zur Laufzeit müssen wenige Dienste diese schreiben, es wird daher empfohlen, dies für die meisten Dienste einzuschalten\&. Für diese Einstellung gelten die gleichen Einschränkungen bezüglich Einhängeausbreitung und Privilegien wie für \fIReadOnlyPaths=\fP und verwandte Aufrufe, siehe oben\&. Standardmäßig aus\&. Falls eingeschaltet und im Benutzermodus oder im Systemmodus aber ohne die Capability \fBCAP_SYS_ADMIN\fP (d\&.h\&. für Dienste, bei denen \fIUser=\fP gesetzt ist) betrieben, wird \fINoNewPrivileges=yes\fP impliziert\&. Beachten Sie, dass diese Option keine indirekten Änderungen an Kerneleinstellungen, die durch IPC\-Aufrufe an andere Prozesse erfolgen, verhindert\&. Allerdings kann \fIInaccessiblePaths=\fP verwandt werden, um die relevanten IPC\-Dateisystemobjekte unzugreifbar zu machen\&. Falls \fIProtectKernelTunables=\fP gesetzt ist, wird \fIMountAPIVFS=yes\fP impliziert\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIProtectKernelModules=\fP .RS 4 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 \fBCAP_SYS_MODULE\fP 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 \fIReadOnlyPaths=\fP 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 \fBkernel\&.modules_disabled\fP von \fBsysctl.d\fP(5) und /proc/sys/kernel/modules_disabled\&. Falls dies eingeschaltet und im Benutzermodus oder im Systemmodus, aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=\fP) betrieben wird, wird \fINoNewPrivileges=yes\fP impliziert\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIProtectKernelLogs=\fP .RS 4 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 \fBCAP_SYSLOG\fP aus der Capability\-Begrenzungsmenge für diese Unit und installiert einen Systemaufruffilter, um den Systemaufruf \fBsyslog\fP(2) (der nicht mit der Libc\-API \fBsyslog\fP(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\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIProtectControlGroups=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls wahr, werden die über /sys/fs/cgroup/ erreichbaren »Linux Control Groups« (\fBcgroups\fP(7))\-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 \fIReadOnlyPaths=\fP und verwandte Aufrufe, siehe oben\&. Standardmäßig aus\&. Falls \fIProtectControlGroups=\fP gesetzt ist, wird \fIMountAPIVFS=yes\fP impliziert\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIRestrictAddressFamilies=\fP .RS 4 Beschränkt die Gruppe der Socket\-Adressfamilien, auf die Prozesse dieser Unit zugreifen können\&. Akzeptiert eine Leerzeichen\-getrennte Liste von freizugebenden Adressfamiliennamen, wie \fBAF_UNIX\fP, \fBAF_INET\fP oder \fBAF_INET6\fP\&. Wird dieser \fB~\fP vorangestellt, wird die Liste der Adressfamilien als Ausschlussliste angewandt, andernfalls als Freigabeliste\&. Beachten Sie, dass dies nur Zugriff auf den Systemaufruf \fBsocket\fP(2) beschränkt\&. Sockets, die auf anderem Wege in die Unit hereingegeben werden (beispielsweise durch Verwendung von Socket\-Aktivierung mit Socket\-Units, siehe \fBsystemd.socket\fP(5)) sind davon nicht betroffen\&. Auch Sockets, die mit \fBsocketpair()\fP (was nur verbundene AF_UNIX\-Sockets erstellt) erstellt werden, sind nicht betroffen\&. Beachten Sie, das diese Option keinen Effekt auf 32\-Bit X86, S390, S390x, MIPS, MIPS\-le, PPC, PPC\-le, 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 \fISystemCallArchitectures=native\fP oder ähnlichem zu kombinieren\&. Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=nobody\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&. Standardmäßig werden keine Einschränkungen angewandt, Prozesse können auf alle Adressfamilien zugreifen\&. Falls die leere Zeichenkette zugewiesen wird, werden alle vorherigen Änderungen der Einschränkung der Adressfamilie zurückgenommen\&. Diese Einstellung betrifft keine Befehle, denen »+« vorangestellt sind\&. .sp Verwenden Sie diese Option, um den Kontakt des Prozesses für Zugriff aus der Ferne, insbesondere über exotische und heikle Netzwerkprotokolle wie \fBAF_PACKET\fP, zu begrenzen\&. Beachten Sie, dass in den meisten Fällen die lokale Adressfamilie \fBAF_UNIX\fP in die konfigurierte Freigabeliste aufgenommen werden sollte, da sie häufig für lokale Kommunikation verwandt wird, einschließlich für die \fBsyslog\fP(2)\-Protokollierung\&. .RE .PP \fIRestrictNamespaces=\fP .RS 4 Begrenzt Zugriff auf die Linux\-Namensraumfunktionalität für die Prozesse dieser Unit\&. Für Details über Linux\-Namensräume siehe \fBnamespaces\fP(7)\&. Akzeptiert entweder ein 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 \fBcgroup\fP, \fBipc\fP, \fBnet\fP, \fBmnt\fP, \fBpid\fP, \fBuser\fP und \fButs\fP bestehen\&. Jeder aufgeführte Namensraumtyp wird den Prozessen der Unit zugreifbar gemacht, Zugriff auf nicht aufgeführte Namensräume sind verboten (Freigabeliste)\&. Durch Voranstellen des Tilde\-Zeichens (»~«) kann der Effekt invertiert werden: nur die aufgeführten Namensraumtypen werden nicht zugreifbar gemacht, alle nicht aufgeführten sind erlaubt (Verbotsliste)\&. Falls die leere Zeichenkette zugewiesen wird, werden die Vorgabe\-Namensraumeinschränkungen angewandt, was zu falsch äquivalent ist\&. Diese Option kann mehr als einmal auftauchen\&. In diesem Fall werden die Namensraumtypen mit \fBODER\fP (oder mit \fBUND\fP, falls den Zeilen »~« vorangestellt wird) zusammengefasst (siehe nachfolgende Beispiele)\&. Intern begrenzt diese Einstellung Zugriff auf die Systemaufrufe \fBunshare\fP(2), \fBclone\fP(2) und \fBsetns\fP(2) und berücksichtigt dabei die festgelegten Schalterparameter\&. Beachten Sie, dass bei Verwendung dieser Option zusätzlich zur Begrenzung der Erstellung und Umschaltung der festgelegten Namensraumtypen (oder allen von ihnen, falls wahr) Zugriff auf den Systemaufruf \fBsetns()\fP mit einem Nullschalterparameter verboten ist\&. Diese Einstellung wird nur auf X86, X86\-64, MIPS, MIPS\-le, MIPS64, MIPS64\-le, MIPS64\-n32, MIPS64\-le\-n32, PPC64, PPC64\-le, S390 und S390x unterstützt und erwirkt auf anderen Architekturen keine Einschränkungen\. Falls der Betrieb im Benutzermodus oder im Systemmodus aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&. .sp Beispiel: Falls eine Unit die Einstellunng .sp .if n \{\ .RS 4 .\} .nf RestrictNamespaces=cgroup ipc RestrictNamespaces=cgroup net .fi .if n \{\ .RE .\} .sp hat, dann werden \fBcgroup\fP, \fBipc\fP und \fBnet\fP gesetzt\&. Falls der zweiten Zeile »~« vorangestellt wird, d\&.h\&. .sp .if n \{\ .RS 4 .\} .nf RestrictNamespaces=cgroup ipc RestrictNamespaces=~cgroup net .fi .if n \{\ .RE .\} .sp dann wird nur \fBipc\fP gesetzt\&. .RE .PP \fILockPersonality=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls gesetzt, sperrt es den Systemaufruf \fBpersonality\fP(2), so dass die Kernel\-Ausführungsdomäne nicht mehr von der Vorgabe oder von der mit der Anweisung \fIPersonality=\fP ausgewählten Personalität geändert werden kann\&. Dies kann zur Verbesserung der Sicherheit nützlich sein, da merkwürdige Personalitätsemulationen schlecht getestet und eine Quelle von Schwachstellen sein können\&. Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&. .RE .PP \fIMemoryDenyWriteExecute=\fP .RS 4 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, der \fBmmap\fP(2)\-Systemaufrufe mit sowohl gesetztem \fBPROT_EXEC\fP als auch gesetztem \fBPROT_WRITE\fP, \fBmprotect\fP(2)\- oder \fBpkey_mprotect\fP(2)\-Systemaufrufe mit gesetztem \fBPROT_EXEC\fP und \fBshmat\fP(2)\-Systemaufrufe mit gesetztem \fBSHM_EXEC\fP 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 \fBnoexec\fP eingehängt ist (wie /dev/shm) oder er \fBmemfd_create\fP() verwenden kann\&. Dies kann verhindert werden, indem solche Dateisysteme für den Dienst unzugreifbar gemacht (z\&.B\&. \fIInaccessiblePaths=/dev/shm\fP) und weitere Systemaufruffilter (\fISystemCallFilter=~memfd_create\fP) installiert werden\&. Beachten Sie, dass diese Funktionalität komplett auf X86\-64 und teilweise auf X86 verfügbar ist\&. Insbesondere der \fBshmat()\fP\-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 \fISystemCallArchitectures=native\fP oder ähnlichem zu kombinieren\&. Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&. .RE .PP \fIRestrictRealtime=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls gesetzt, werden alle Versuche, Echtzeit\-Scheduling für einen Prozess der Unit zu aktivieren, abgelehnt\&. Damit wird Zugriff auf die Echtzeitprogramm\-Scheduling\-Richtlinien wie \fBSCHED_FIFO\fP, \fBSCHED_RR\fP oder \fBSCHED_DEADLINE\fP begrenzt\&. Siehe \fBsched\fP(7) für Details über diese Scheduling\-Richtlinien\&. Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&. Echtzeit\-Scheduling\-Richtlinien können zur Monopolisierung von CPU\-Zeit für längere Zeitperioden verwandt werden und können daher dazu verwandt werden, das System zu sperren oder anderweitige Diensteverweigerungssituationen auf dem System auszulösen\&. Es wird daher empfohlen, den Zugriff auf Echtzeit\-Scheduling auf die wenigen Programme, die dies tatsächlich benötigen, zu begrenzen\&. Standardmäßig aus\&. .RE .PP \fIRestrictSUIDSGID=\fP .RS 4 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 \fBinode\fP(7))\&.Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&. 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 \fIDynamicUser=\fP aktiviert ist\&. Standardmäßig »off«\&. .RE .PP \fIRemoveIPC=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls gesetzt, werden alle System\-V\- und POSIX\-IPC\-Objekte, die dem Benutzer und der Gruppe, unter der diese Unit läuft, gehören, entfernt, wenn die Unit gestoppt wird\&. Diese Einstellung hat nur einen Effekt, falls eines aus \fIUser=\fP, \fIGroup=\fP oder \fIDynamicUser=\fP verwandt wird\&. Es hat keinen Effekt für IPC\-Objekte, die dem Benutzer »root« gehören\&. Insbesondere entfernt dies System\-V\-Semaphoren sowie gemeinsam benutzte Segmente und Nachrichten\-Warteschlangen gemäß System V und POSIX\&. Falls mehrere Units die gleichen Benutzer oder Gruppen verwenden, werden die IPC\-Objekte entfernt, wenn die letzte dieser Units gestoppt wird\&. Diese Einstellung ist impliziert, falls \fIDynamicUser=\fP gesetzt ist\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIPrivateMounts=\fP .RS 4 Akzeptiert einen logischen Parameter\&. Falls gesetzt, wird diese Unit in ihrem eigenen privaten Dateisystem (Einhänge\-)Namensraum betrieben, wobei alle Einhängeausbreitungen von dem Prozess in Richtung des Hauptdateisystems des Rechners abgeschaltet sind\&. Dies bedeutet, dass alle vom Prozess etablierten oder entfernten Dateisystemeinhängepunkte für diese privat und nicht im Hauptsystem sichtbar sind\&. Allerdings werden Dateisystemeinhängepunkte, die auf dem System etabliert oder entfernt werden, sich zu den Prozessen der Unit ausbreiten\&. Siehe \fBmount_namespaces\fP(7) für Details bezüglich Dateisystemnamensräumen\&. Standardmäßig aus\&. .sp Falls eingeschaltet, wird dies drei Aktionen für jeden aufgerufenen Prozess auslösen: ein neuer \fBCLONE_NEWNS\fP\-Namensraum wird erstellt, danach werden alle existierenden Einhängungen neu als \fBMS_SLAVE\fP eingehängt, um die Ausbreitung aus den Prozessen der Unit zu dem Hauptsystem zu deaktivieren (aber die Ausbreitung in die umgekehrte Richtung bleibt wirksam)\&. Schließlich werden die Einhängungen erneut gemäß des in dem Schalter \fIMountFlags=\fP konfigurierten Ausbreitungsmodus eingehängt, siehe unten\&. .sp Dateisystemnamensräume werden individuell für jeden mit »fork« vom Diensteverwalter gestarteten Prozess eingerichtet\&. Einhängungen, die im Namensraum des durch \fIExecStartPre=\fP erstellten Prozesses etabliert wurden, werden daher automatisch bereinigt, sobald der Prozess sich beendet und werden für nachfolgend durch \fIExecStart=\fP mit Fork gestartete Prozesse nicht verfügbar sein (und Ähnliches gilt auch für die verschiedenen anderen für Units konfigurierten Befehle)\&. Ähnlich erlaubt \fIJoinsNamespaceOf=\fP nicht die gemeinsame Benutzung von Kernelnamensräumen zwischen Units, es ermöglicht nur die gemeinsame Benutzung der Verzeichnisse /tmp/ und /var/tmp/\&. .sp Andere Dateisystemnamensräume\-Einstellungen für Units \(em \fIPrivateMounts=\fP, \fIPrivateTmp=\fP, \fIPrivateDevices=\fP, \fIProtectSystem=\fP, \fIProtectHome=\fP, \fIReadOnlyPaths=\fP, \fIInaccessiblePaths=\fP, \fIReadWritePaths=\fP, … \(em ermöglichen Dateisystemnamensräume in einer Art ähnlich dieser Option\&. Daher ist es primär zur expliziten Anfrage dieses Verhalten nützlich, falls keine der anderen Einstellungen verwandt wird\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fIMountFlags=\fP .RS 4 Akzeptiert eine Einhängeausbreitungseinstellung: \fBshared\fP, \fBslave\fP oder \fBprivate\fP, die steuert, ob Dateisystemeinhängepunkte, die für die Prozesse dieser Unit in dem Dateisystemnamensraum eingerichtet wurden, Einhängungen oder Aushängungen aus anderen Dateisystemnamensräumen empfangen oder ausbreiten\&. Siehe \fBmount\fP(2) für Details über Einhängeausbreitungen und insbesondere die drei Ausbreitungsschalter\&. .sp Diese Einstellung steuert nur die \fIabschließenden\fP Ausbreitungseinstellungen, die für alle Einhängepunkte des Dateisystemnamensraums, der für jeden Prozess dieser Unit erstellt wurde, wirksam sind\&. Andere Dateisystemnamensraum\-Unit\-Einstellungen (siehe die Diskussion in \fIPrivateMounts=\fP oben) werden implizit Einhänge\- und Aushängeausbreitung von den Prozessen der Unit in Richtung des Systems deaktivieren, indem sie die Ausbreitungseinstellungen aller Einhängepunkte in dem Dateisystemnamensraum der Unit zuerst auf \fBslave\fP setzen\&. Setzen der Option auf \fBshared\fP richtet die Ausbreitung in diesem Fall nicht wieder ein\&. .sp Falls nicht gesetzt \(en aber es sind durch andere Dateisystemnamensraumeinstellungen der Unit keine Dateisystemnamensräume aktiviert \(en, wird \fBshared\fP Einhängeausbreitung verwandt, aber wie erwähnt, wird \fBslave\fP zuerst angewandt, Ausbreitung von den Prozessen der Unit zum Hauptsystem bleibt weiterhin abgeschaltet\&. .sp Es wird nicht empfohlen, \fBprivate\fP Einhängeausbreitung für Units zu verwenden, da dies bedeutet, dass temporäre Einhängungen (wie Wechselmedien) auf dem Hauptsystem eingehängt bleiben und daher unbefristet in mit Fork erstellten Programmen als beschäftigt markiert sind, da die Aushängeausbreitungsereignisse in dem Dateisystemnamensraum der Unit nicht empfangen werden\&. .sp Normalerweise ist es am besten, diese Einstellung unverändert zu lassen und stattdessen abstraktere Dateisystemnamensraumoptionen zu verwenden, insbesondere \fIPrivateMounts=\fP, siehe oben\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .SH SYSTEMAUFRUFFILTERUNG .PP \fISystemCallFilter=\fP .RS 4 Akzeptiert eine Leerzeichen\-getrennte Liste von Systemaufrufenamen\&. Falls diese Einstellung verwandt wird, werden alle Systemaufrufe, die durch die Prozesse der Unit ausgeführt werden, zu sofortiger Beendigung mit dem Signal \fBSIGSYS\fP führen, falls sie nicht aufgeführt sind (Freigabeliste)\&. (Siehe \fISystemCallErrorNumber=\fP zur Änderung der Standardaktion)\&. Falls das erste Zeichen der Liste »~« ist, wird die Wirkung invertiert: nur die aufgeführten Systemaufrufe führen zu einer sofortigen Prozessbeendigung (Verbotsliste)\&. Freigegebenen Systemaufrufen und Systemaufrufgruppen kann optional ein Doppelpunkt (»:«) und »errno«\-Fehlernummern (zwischen 0 und 4095) oder Fehlernummernamen wie \fBEPERM\fP, \fBEACCES\fP oder \fBEUCLEAN\fP (siehe \fBerrno\fP(3) für eine komplette Liste) angehängt werden\&. Dieser Wert wird zurückgeliefert, wenn ein verbotener Systemaufruf ausgelöst wird, statt den Prozess sofort zu beenden\&. Die besondere Einstellung »kill« kann zur expliziten Angabe des Tötens verwandt werden\&. Dieser Wert hat vor dem in \fISystemCallErrorNumber=\fP angegebenen Vorrang, siehe unten\&. Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=nobody\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&. Diese Funktionalität verwendet die Schnittstelle »Secure Computing Mode 2« des Kernels (»Seccomp\-Filterung«) und ist nützlich, um eine minimale Sandboxing\-Umgebung zu erzwingen\&. Beachten Sie, dass die Systemaufrufe \fBexecve()\fP, \fBexit()\fP, \fBexit_group()\fP, \fBgetrlimit()\fP, \fBrt_sigreturn()\fP, \fBsigreturn()\fP und die Systemaufrufe zur Abfrage der Zeit und zum Schlafen implizit auf der Freigabeliste sind und nicht explizit aufgelistet werden müssen\&. Diese Option kann mehr als einmal angegeben werden, die Filtermasken werden in diesem Fall zusammengeführt\&. Falls die leere Zeichenkette zugewiesen wird, wird der Filter zurückgesetzt und alle vorherigen Zuweisungen haben keine Wirkung\&. Diese betrifft Befehle, denen »+« vorangestellt ist, nicht\&. .sp Beachten Sie, dass auf Systemen, die mehrere ABIs unterstützen (wie X86/X86\-64), empfohlen wird, alternative ABIs für Dienste zu deaktivieren, so dass sie nicht zur Umgehung der Einschränkungen dieser Option verwandt werden können\&. Insbesondere wird empfohlen, diese Option mit \fISystemCallArchitectures=native\fP oder Ähnlichem zu kombinieren\&. .sp Beachten Sie, dass strenge Systemaufruffilterung die Ausführungs\- und Fehlerbehandlungs\-Code\-Pfade des Diensteaufrufs beeinflussen können\&. Insbesondere wird der Zugriff auf den Systemaufruf \fBexecve()\fP für die Ausführung des Diensteprogrammes benutzt \(em falls er blockiert ist, wird der Diensteaufruf notwendigerweise fehlschlagen\&. Falls auch die Ausführung des Diensteprogramms aus irgendwelchen Gründen fehlschlägt (beispielsweise fehlendes Diensteprogramm), könnte die Fehlerbehandlungslogik Zugriff auf eine zusätzliche Gruppe an Systemaufrufen benötigen, um diesen Fehlschlag korrekt zu verarbeiten und zu protokollieren\&. Es könnte notwendig sein, temporär die Systemaufruffilter zu deaktivieren, um die Fehlersuche bei solchen Fehlschlägen zu vereinfachen\&. .sp Falls Sie beide Arten dieser Option (d\&.h\&. explizite Freischaltung und Ausschlussliste) festlegen, wird die erste angetroffene Vorrang haben und die Standardaktion festlegen (Beendigung oder Bestätigung eines Systemaufrufs)\&. Dann wird das nächste Auftreten dieser Option die Liste der Systemaufrufe zu der Menge der gefilterten Systemaufrufe hinzufügen oder aus dieser löschen, abhängig von seiner Art und der Standardaktion\&. (Falls Sie beispielsweise mit einer expliziten Freischaltung von \fBread()\fP und \fBwrite()\fP beginnen und direkt danach eine Ausschlussliste mit \fBwrite()\fP hinzufügen, dann wird \fBwrite()\fP aus der Menge entfernt\&.) .sp Da die Anzahl der möglichen Systemaufrufe groß ist, werden vordefinierte Gruppen von Systemaufrufen bereitgestellt\&. Eine Gruppe beginnt mit dem Zeichen »@«, gefolgt vom Namen der Gruppe\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&4.\ \&Derzeit vordefinierte Systemaufrufgruppen\fP .TS allbox tab(:); lB lB. T{ Gruppe T}:T{ Beschreibung T} .T& l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l. T{ @aio T}:T{ Asynchrone E/A (\fBio_setup\fP(2), \fBio_submit\fP(2) und verwandte Aufrufe) T} T{ @basic\-io T}:T{ Systemaufrufe für grundlegende E/A: Lesen, Schreiben, Suchen, Duplizieren und Schließen von Dateideskriptoren (\fBread\fP(2), \fBwrite\fP(2) und verwandte Aufrufe) T} T{ @chown T}:T{ Änderung der Dateieigentümerschaft (\fBchown\fP(2), \fBfchownat\fP(2) und verwandte Aufrufe) T} T{ @clock T}:T{ Systemaufrufe zur Änderung der Systemuhr (\fBadjtimex\fP(2), \fBsettimeofday\fP(2) und verwandte Aufrufe) T} T{ @cpu\-emulation T}:T{ Systemaufrufe für CPU\-Emulierungsfunktionen (\fBvm86\fP(2) und verwandte Aufrufe) T} T{ @debug T}:T{ Fehlersuche, Leistungsüberwachung und Nachverfolgungsfunktionen (\fBptrace\fP(2), \fBperf_event_open\fP(2) und verwandte Aufrufe) T} T{ @file\-system T}:T{ Dateisystemaktionen: Öffnen, Dateien und Verzeichnisse zum Lesen und Schreiben erstellen, sie umbenennen oder entfernen, Lesen von Dateieigenschaften oder Erstellen von harten und symbolischen Links T} T{ @io\-event T}:T{ Systemaufrufe für Ereignisschleifen (\fBpoll\fP(2), \fBselect\fP(2), \fBepoll\fP(7), \fBeventfd\fP(2) und verwandte Aufrufe) T} T{ @ipc T}:T{ Pipes, SysV IPC, POSIX\-Nachrichtenwarteschlangen und andere IPC (\fBmq_overview\fP(7), \fBsvipc\fP(7)) T} T{ @keyring T}:T{ Kernel\-Schlüsselbundzugriff (\fBkeyctl\fP(2) und verwandte Aufrufe) T} T{ @memlock T}:T{ Sperren von Speicher im RAM (\fBmlock\fP(2), \fBmlockall\fP(2) und verwandte Aufrufe) T} T{ @module T}:T{ Laden und Entladen von Kernelmodulen (\fBinit_module\fP(2), \fBdelete_module\fP(2) und verwandte Aufrufe) T} T{ @mount T}:T{ Einhängen und Aushängen von Dateisystemen (\fBmount\fP(2), \fBchroot\fP(2) und verwandte Aufrufe) T} T{ @network\-io T}:T{ Socket\-E/A (einschließlich lokalem AF_UNIX): \fBsocket\fP(7), \fBunix\fP(7) T} T{ @obsolete T}:T{ Ungewöhnliches, Veraltetes oder nicht Implementiertes (\fBcreate_module\fP(2), \fBgtty\fP(2), …) T} T{ @privileged T}:T{ Alle Systemaufrufe, die Administrator\-Capabilities benötigen (\fBcapabilities\fP(7)) T} T{ @process T}:T{ Prozesssteuerung, \-ausführung, Namensraumaktionen (\fBclone\fP(2), \fBkill\fP(2), \fBnamespaces\fP(7), …) T} T{ @raw\-io T}:T{ Rohzugriff auf E/A\-Ports (\fBioperm\fP(2), \fBiopl\fP(2), \fBpciconfig_read()\fP, …) T} T{ @reboot T}:T{ Systemaufrufe für den Neustart und die Neustartvorbereitung (\fBreboot\fP(2), \fBkexec()\fP, …) T} T{ @resources T}:T{ Systemaufrufe für die Änderung von Ressourcenbeschränkungen, Speicher\- und Schedulingparametern (\fBsetrlimit\fP(2), \fBsetpriority\fP(2), …) T} T{ @setuid T}:T{ Systemaufrufe zur Änderung der Benutzerkennung und Gruppenberechtigungen (\fBsetuid\fP(2), \fBsetgid\fP(2), \fBsetresuid\fP(2), …) T} T{ @signal T}:T{ Systemaufrufe für die Veränderung und Handhabung von Prozesssignalen (\fBsignal\fP(2), \fBsigprocmask\fP(2), …) T} T{ @swap T}:T{ Systemaufrufe für die Aktivierung/Deaktivierung von Auslagerungsgeräten (\fBswapon\fP(2), \fBswapoff\fP(2)) T} T{ @sync T}:T{ Synchronisierung von Dateien und Speicher auf Platte (\fBfsync\fP(2), \fBmsync\fP(2) und verwandte Aufrufe) T} T{ @system\-service T}:T{ Eine vernünftige Gruppe von Systemaufrufen, die von typischen Systemdiensten benutzt werden, ausschließlich aller Systemaufrufe für besondere Zwecke\&. Dies ist der empfohlene Anfangspunkt zum expliziten Erlauben von Systemaufrufen für Systemdienste, da es das enthält, was typischerweise von Systemdiensten benötigt wird, aber äußerst spezielle Schnittstellen ausschließt\&. Beispielsweise sind die folgenden APIs ausgeschlossen: »@clock«, »@mount«, »@swap«, »@reboot«\&. T} T{ @timer T}:T{ Systemaufrufe für Scheduling\-Aktionen von Time (\fBalarm\fP(2), \fBtimer_create\fP(2), …) T} T{ @known T}:T{ Alle durch den Kernel definierten Systemaufrufe\&. Diese Liste ist in Systemd statisch basierend auf der Kernelversion, die bei der Veröffentlichung von Systemd verfügbar war, definiert\&. Sie wird fortschreidend veralten, wenn der Kernel aktualisiert wird\&. T} .TE .sp 1 Beachten Sie, dass neue Systemaufrufe zu den obigen Gruppen hinzugefügt werden könnten, wenn neue Systemaufrufe zu dem Kernel hinzugefügt werden\&. Die Inhalte dieser Gruppen können sich auch zwischen Systemd\-Versionen unterscheiden\&. Zusätzlich hängt die Liste der Systemaufrufe auch von der Kernelversion und der Architektur, für die Systemd kompiliert wurde, ab\&. Verwenden Sie \fBsystemd\-analyze\ \&syscall\-filter\fP, um die tatsächliche Liste der Systemaufrufe in jedem Filter aufzuführen\&. .sp Im Allgemeinen ist das explizite Erlauben von Systemaufrufen (statt einer Ausschlussliste) der sicherere Betriebsmodus\&. Es wird empfohlen, für alle langlaufenden Systemdienste eine Liste explizit erlaubter Systemaufrufe zu erzwingen\&. Insbesondere sind die nachfolgenden Zeilen eine relativ sicherere grundlegende Wahl für den Großteil der Systemdienste: .sp .if n \{\ .RS 4 .\} .nf [Service] SystemCallFilter=@system\-service SystemCallErrorNumber=EPERM .fi .if n \{\ .RE .\} .sp Beachten Sie, dass die verschiedenen Systemaufrufe redundant definiert werden: es gibt mehrere Systemaufrufe zur Ausführung der gleichen Aktion\&. Beispielsweise kann der Systemaufruf \fBpidfd_send_signal()\fP zur Ausführung von Aktionen ähnlich zu dem älteren Systemaufruf \fBkill()\fP verwandt werden, daher führt das Blockieren von letzterem ohne das Blockieren des ersteren nur zu einem schwachen Schutz\&. Da neue Systemaufrufe regelmäßig dem Kernel hinzugefügt werden, verlangt das Pflegen von vollständigen Ausschlusslisten für Systemaufrufe ständige Arbeit\&. Es wird daher empfohlen, stattdessen Freischaltungen einzusetzen, wodurch der Nutzen entsteht, dass neue Systemaufrufe standardmäßig implizit blockiert sind, bis die Freischaltung aktualisiert wurde\&. .sp Beachten Sie auch, dass eine Reihe von Systemaufrufen zugreifbar sein müssen, damit der dynamische Linker funktioniert\&. Der dynamische Linker wird zur Ausführung der meisten regulären Programme benötigt (konkret dynamische ELF\-Programme \- auf diese Art bauen die meisten Distributionen paketierte Programme)\&. Dies bedeutet, dass das Blockieren dieser Systemaufrufe (wozu \fBopen()\fP, \fBopenat()\fP und \fBmmap()\fP gehören) dazu führen wird, das die meisten mit generischen Distributionen ausgelieferten Programme unbenutzbar werden\&. .sp Es wird empfohlen, die auf den Namensraum des Dateisystems bezogenen Optionen mit \fISystemCallFilter=~@mount\fP zu kombinieren, um zu verhindern, dass die Prozesse der Unit die Abbildungen rückgängig machen\&. Insbesondere sind dies die Optionen \fIPrivateTmp=\fP, \fIPrivateDevices=\fP, \fIProtectSystem=\fP, \fIProtectHome=\fP, \fIProtectKernelTunables=\fP, \fIProtectControlGroups=\fP, \fIProtectKernelLogs=\fP, \fIProtectClock=\fP, \fIReadOnlyPaths=\fP, \fIInaccessiblePaths=\fP und \fIReadWritePaths=\fP\&. .RE .PP \fISystemCallErrorNumber=\fP .RS 4 Akzeptiert eine »errno«\-Fehlernummer (zwischen 1 und 4095) oder einen Errno\-Namen wie \fBEPERM\fP, \fBEACCES\fP oder \fBEUCLEAN\fP, der zurückgeliefert werden soll, wenn der mit \fISystemCallFilter=\fP konfigurierte Systemaufruffilter ausgelöst wird, statt den Prozess sofort zu beenden\&. Siehe \fBerrno\fP(3) für eine vollständige Liste der Fehlercodes\&. Wenn diese Einstellung nicht benutzt wird, oder wenn ihm die leere Zeichenkette oder die besondere Einstellung »kill« zugewiesen wird, wird der Prozess sofort beendet, wenn der Filter ausgelöst wird\&. .RE .PP \fISystemCallArchitectures=\fP .RS 4 Akzeptiert eine Leerzeichen\-getrennte Liste von Architekturkennungen, die in den Systemaufrufilter einbezogen werden sollen\&. Die bekannten Architekturkennungen sind die gleichen wie für das in \fBsystemd.unit\fP(5) beschriebene \fIConditionArchitecture=\fP, sowie \fBx32\fP, \fBmips64\-n32\fP, \fBmips64\-le\-n32\fP und die besondere Kennung \fBnative\fP\&. Die besondere Kennung \fBnative\fP wird implizit auf die native Architektur des Systems abgebildet (oder genauer: auf die Architektur, für die der Systemverwalter kompiliert wurde)\&. Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=nobody\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&. Standardmäßig wird diese Option auf die leere Liste gesetzt, d\&.h\&. keine Filterung erfolgt\&. .sp Falls diese Einstellung verwandt wird, wird den Prozessen dieser Unit nur der Aufruf nativer Systemaufrufe und von Systemaufrufen der festgelegten Architektur erlaubt\&. Für die Zwecke dieser Option wird die Architektur X32 so behandelt, dass sie die Systemaufrufe von X86\-64 enthält\&. Allerdings erfüllt diese Einstellung auf X32 weiterhin ihren Zweck, wie unten dargestellt\&. .sp Systemaufruffilterung ist nicht auf allen Architekturen wirksam\&. Beispielsweise ist auf X86 aufgrund von ABI\-Einschränkungen das Filtern von Netz\-Socket\-bezogenen Aufrufen nicht möglich, eine Einschränkung, die X86\-64 allerdings nicht hat\&. Auf Systemen, die mehrere ABI gleichzeitig unterstützen, wie X86/X86\-64, wird daher empfohlen, die Gruppe der erlaubten Systemaufrufarchitekturen einzuschränken, so dass das sekundäre ABI nicht dazu verwandt werden kann, die dem nativen ABI des Systems auferlegten Einschränkungen zu umgehen\&. Insbesondere ist das Setzen von \fISystemCallArchitectures=native\fP für das Deaktivieren nichtnativer ABIs eine gute Wahl\&. .sp Systemaufrufarchitekturen können auch systemweit mittels der Option \fISystemCallArchitectures=\fP in der globalen Konfiguration eingeschränkt werden\&. Siehe \fBsystemd\-system.conf\fP(5) für Details\&. .RE .PP \fISystemCallLog=\fP .RS 4 Akzeptiert eine Leerzeichen\-getrennte Liste von Systemaufrufenamen\&. Falls diese Einstellung verwandt wird, werden alle aufgeführten Systemaufrufe, die durch die Prozesse der Unit ausgeführt werden, protokolliert\&. Falls das erste Zeichen der Liste »~« ist, wird die Wirkung invertiert: alle außer den aufgeführten Systemaufrufen werden protokolliert\&. Falls der Betrieb im Benutzermodus oder im Systemmodus, aber ohne die Capability \fBCAP_SYS_ADMIN\fP (z\&.B\&. durch Setzen von \fIUser=nobody\fP) erfolgt, wird \fINoNewPrivileges=yes\fP impliziert\&. Diese Funktionalität verwendet die Schnittstelle »Secure Computing Mode 2« des Kernels (»Seccomp\-Filterung«) und ist nützlich, um die Sandboxing\-Umgebung zu auditieren oder einzurichten\&. Diese Option kann mehr als einmal angegeben werden, die Filtermasken werden in diesem Fall zusammengeführt\&. Falls die leere Zeichenkette zugewiesen wird, wird der Filter zurückgesetzt und alle vorherigen Zuweisungen haben keine Wirkung\&. Diese betrifft Befehle, denen »+« vorangestellt ist, nicht\&. .RE .SH UMGEBUNGSVARIABLEN .PP \fIEnvironment=\fP .RS 4 Setzt Umgebungsvariablen für ausgeführte Prozesse\&. Akzeptiert eine Leerzeichen\-getrennte Liste von Variablenzuweisungen\&. Diese Option kann mehr als einmal angegeben werden, dann werden alle aufgeführten Variablen gesetzt\&. Falls die gleiche Variable zweimal gesetzt ist, wird die spätere Einstellung die frühere Einstellung außer Kraft setzen\&. Falls der Option die leere Zeichenkette zugewiesen wird, wird die Liste der Umgebungsvariablen zurückgesetzt und alle vorhergehenden Zuweisungen haben keine Wirkung\&. Innerhalb der Zeichenkette wird keine Variablenexpansion durchgeführt, es ist allerdings eine Kennzeichner\-Expansion möglich\&. Das Zeichen »$« hat keine besondere Bedeutung\&. Falls Sie einen Wert, der Leerzeichen oder Gleichheitszeichen enthält, einer Variablen zuweisen müssen, verwenden Sie doppelte Anführungszeichen (") für die Zuweisung\&. .sp Die Namen der Variablen dürfen ASCII\-Buchstaben, Ziffern und der Unterstrich enthalten sein\&. Variablennamen dürfen nicht leer sein oder mit einer Ziffer beginnen\&. In den Variablenwerten sind die meisten Zeichen erlaubt, aber nicht darstellbare Zeichen werden derzeit zurückgewiesen\&. .sp Beispiel: .sp .if n \{\ .RS 4 .\} .nf Environment="VAR1=Wort1 Wort2" VAR2=Wort3 "VAR3=$Wort 5 6" .fi .if n \{\ .RE .\} .sp ergibt drei Variablen »VAR1«, »VAR2«, »VAR3« mit den Werten »Wort1 Wort2«, »Wort3«, »$Wort 5 6«\&. .sp Siehe \fBenviron\fP(7) für Details über Umgebungsvariablen\&. .sp Beachten Sie, dass Umgebungsvariablen nicht dazu geeignet sind, Geheimnisse (wie Passwörter, Schlüsselmaterial, …) an Diensteprozesse weiterzugeben\&. Für eine Unit gesetzte Umgebungsvariablen können von nicht privilegierten Clients wie D\-Bus\-IPC eingesehen werden und werden im Allgemeinen nicht als Daten betrachtet, die geschützt werden müssen\&. Desweiteren werden Umgebungsvariablen den Prozessbaum heruntergereicht, auch über Sicherheitsgrenzen (wie Setuid/Setgid\-Programme) hinweg und könnten daher zu Prozessen durchsickern, die keinen Zugriff auf die geheimen Daten haben sollen\&. Verwenden Sie \fILoadCredential=\fP (siehe unten), um Daten sicher an Unit\-Prozesse zu übergeben\&. .RE .PP \fIEnvironmentFile=\fP .RS 4 Ähnlich zu \fIEnvironment=\fP, liest aber die Umgebungsvariablen aus einer Textdatei\&. Die Textdatei sollte durch Zeilenumbrüche getrennte Variablenzuweisungen enthalten\&. Leere Zeilen, Zeilen ohne einen »=«\-Trenner und Zeilen, die mit ; oder # beginnen, werden ignoriert\&. Letzteres kann zur Kommentierung verwandt werden\&. Eine Zeile, die mit einem Rückwärtsschrägstrich endet, wird mit der nachfolgenden verbunden, wodurch mehrzeilige Variablendefinitionen ermöglicht werden\&. Das Auswertprogramm entfernt Leerraumzeichen am Anfang und Ende der Zeile von den Werten der Zuweisungen, falls Sie keine doppelten Anführungszeichen (") verwenden\&. .sp \m[blue]\fBC\-Maskierungen\fP\m[]\&\s-2\u[7]\d\s+2 werden unterstützt, aber nicht die \m[blue]\fBmeisten Steuerzeichen\fP\m[]\&\s-2\u[8]\d\s+2\&. Es können »\et« und »\en« zum Einfügen von Tabulatoren und Zeilenumbrüchen in \fIEnvironmentFile=\fP verwandt werden\&. .sp Das übergebene Argument sollte ein absoluter Dateiname oder ein Platzhalterausdruck sein, dem optional »\-« vorangestellt werden kann, um anzuzeigen, dass sie nicht gelesen werden soll und keine Fehler\- oder Warnmeldung protokolliert wird, falls sie nicht existiert\&. Diese Option kann mehr als einmal angegeben werden, in diesem Fall werden alle festgelegten Dateien gelesen\&. Falls der Option die leere Zeichenkette zugewiesen wird, wird die Liste der zu lesenden Dateien zurückgesetzt und alle vorherigen Zuweisungen haben keine Wirkung\&. .sp Die mit dieser Anweisung aufgeführten Dateien werden kurz vor der Ausführung des Prozesses gelesen (genauer gesagt, nachdem alle Prozesse eines vorherigen Unit\-Zustandes beendet wurden\&. Dies bedeutet, dass Sie diese Dateien in einem Unit\-Zustand erstellen und sie mit dieser Option in dem nächsten lesen können\&. Diese Dateien werden aus dem Dateisystem des Diensteverwalters gelesen, bevor Änderungen im Dateisystem wie Bind\-Einhängungen stattfinden)\&. .sp Einstellungen von diesen Dateien setzen mit \fIEnvironment=\fP vorgenommene Einstellungen außer Kraft\&. Falls die gleiche Variable zweimal von diesen Dateien gesetzt wird, werden die Dateien in der festgelegten Reihenfolge eingelesen und spätere Einstellungen werden die früheren Einstellungen außer Kraft setzen\&. .RE .PP \fIPassEnvironment=\fP .RS 4 Übergibt für den Diensteverwalter gesetzte Umgebungsvariablen an ausgeführte Prozesse\&. Akzeptiert eine Leerzeichen\-getrennte Liste von Variablennamen\&. Diese Option kann mehr als einmal angegeben werden, dann werden alle aufgeführten Variablen übergeben\&. Falls dieser Option die leere Zeichenkette zugewiesen wird, wird die Liste der zu übergebenden Umgebungsvariablen zurückgesetzt, alle vorherigen Zuweisungen haben keine Wirkung\&. Festgelegte Variablen, die für den Systemverwalter nicht gesetzt sind, werden nicht übergeben und werden ohne Rückmeldung ignoriert\&. Beachten Sie, dass diese Option nur für den Systemdiensteverwalter relevant ist, da Systemdienste standardmäßig keine Umgebungsvariablen, die für den Diensteverwalter gesetzt sind, erben\&. Im Falle des Benutzerdiensteverwalters werden alle Umgebungsvariablen sowieso an den ausgeführten Prozess übergeben, daher hat diese Option für Benutzerdiensteverwalter keine Wirkung\&. .sp Variablen, die aufgrund dieser Einstellung für aufgerufene Prozesse gesetzt werden, könnten durch solche, die mit \fIEnvironment=\fP oder \fIEnvironmentFile=\fP konfiguriert wurden, außer Kraft gesetzt zu werden\&. .sp \m[blue]\fBC\-Maskierungen\fP\m[]\&\s-2\u[7]\d\s+2 werden unterstützt, aber nicht die \m[blue]\fBmeisten Steuerzeichen\fP\m[]\&\s-2\u[8]\d\s+2\&. Es können »\et« und »\en« zum Einfügen von Tabulatoren und Zeilenumbrüchen in \fIEnvironmentFile=\fP verwandt werden\&. .sp Beispiel: .sp .if n \{\ .RS 4 .\} .nf PassEnvironment=VAR1 VAR2 VAR3 .fi .if n \{\ .RE .\} .sp übergibt die drei Variablen »VAR1«, »VAR2«, »VAR3« mit den für diese Variablen in PID1 gesetzten Werten\&. .sp Siehe \fBenviron\fP(7) für Details über Umgebungsvariablen\&. .RE .PP \fIUnsetEnvironment=\fP .RS 4 Setzt die Variablenzuweisungen, die normalerweise von dem Diensteverwalter an den aufgerufenen Prozess dieser Unit weitergegeben würden, zurück\&. Akzeptiert eine Lerraum\-getrennte Liste von Variablennamen oder Variablenzuweisungen\&. Diese Option kann mehr als einmal angegeben werden, dann werden alle aufgeführten Variablen/Zuweisungen zurückgesetzt\&. Falls der Option die leere Zeichenkette zugewiesen wird, wird die Liste der Umgebungsvariablen/Zuweisungen, die zurückgesetzt werden sollen, zurückgesetzt\&. Falls eine Variablenzuweisung festgelegt ist (das heißt: einem Variablennamen, dem ein »=« und sein Wert folgt), dann wird jede Umgebungsvariable, die exakt auf diese Zuweisung passt, entfernt\&. Falls ein Variablennname festgelegt ist (das ist ein Variablenname, dem kein »=« oder ein Wert folgt), dann wird jede Zuweisung, die auf diesen Variablennamen passt, entfernt, unabhängig von dessen Wert\&. Beachten Sie, dass die Wirkung von \fIUnsetEnvironment=\fP als abschließender Schritt angewandt wird, wenn die an den auszuführenden Prozess zu übergebende Umgebungsliste zusammengestellt wird\&. Das bedeutet, dass es Zuweisungen von jeder Konfigurationsquelle rückgängig machen könnte, einschließlich Zuweisungen, die mittels \fIEnvironment=\fP oder \fIEnvironmentFile=\fP erfolgten, die von der globalen Menge der Umgebungsvariablen des Systemverwalters geerbt wurden, die vom Diensteverwalter selbst gesetzt wurden (wie \fI$NOTIFY_SOCKET\fP und ähnliche) oder die durch ein PAM\-Modul gesetzt wurden (falls \fIPAMName=\fP benutzt wird)\&. .sp Siehe nachfolgenden Abschnitt »Umgebungsvariablen in erzeugten Prozessen« für eine Beschreibung, wie diese Einstellungen kombiniert werden, um eine vererbte Umgebung zu bilden\&. Siehe \fBenviron\fP(7) für allgemeine Informationen über Umgebungsvariablen\&. .RE .SH "PROTOKOLLIERUNG UND SYSTEM\-EIN\-/\-AUSGABE" .PP \fIStandardInput=\fP .RS 4 Steuert, womit der Dateideskriptor 0 (STDIN) des ausgeführten Prozesses verbunden ist\&. Akzeptiert \fBnull\fP, \fBtty\fP, \fBtty\-force\fP, \fBtty\-fail\fP, \fBdata\fP, \fBfile:\fP\fIPfad\fP, \fBsocket\fP oder \fBfd:\fP\fIName\fP\&. .sp Falls \fBnull\fP ausgewählt wird, wird die Standardeingabe mit /dev/null verbunden, d\&.h\&. alle Leseversuche durch den Prozess werden sofort zu einem EOF führen\&. .sp Falls \fBtty\fP ausgewählt ist, wird die Standardeingabe mit einem TTY (wie mit \fITTYPath=\fP konfiguriert, siehe unten) verbunden und der ausgeführte Prozess wird der steuernde Prozess des Terminals\&. Falls das Terminal bereits durch einen anderen Prozess gesteuert wird, wartet der ausgeführte Prozess, bis der derzeit steuernde Prozess das Terminal freigibt\&. .sp \fBtty\-force\fP ist ähnlich zu \fBtty\fP, der ausgeführte Prozess wird aber zwangsweise und sofort zum steuernden Prozess des Terminals gemacht, möglicherweise werden dabei vorhergehende steuernde Prozesse von dem Terminal entfernt\&. .sp \fBtty\-fail\fP ist ähnlich zu \fBtty\fP, falls aber das Terminal bereits einen steuernden Prozess hat, schlägt das Hochfahren des ausgeführten Prozesses fehl\&. .sp Die Option \fBdata\fP kann zur Konfiguration beliebiger textueller oder binärer Daten, die mittels Standardeingabe an den ausgeführten Prozess übergeben werden sollen, verwandt werden\&. Die zu übergebenden Daten werden mittels \fIStandardInputText=\fP/\fIStandardInputData=\fP (siehe unten) konfiguriert\&. Beachten Sie, dass der tatsächlich übergebene Dateideskriptortyp (Speicherdatei, reguläre Datei, UNIX\-Pipe, …) vom Kernel und den verfügbaren Privilegien abhängen könnte\&. Auf jeden Fall ist der Dateideskriptor nur lesbar und er liefert die festgelegten Daten, gefolgt von EOF, zurück, wenn er gelesen wird\&. .sp Die Option \fBfile:\fP\fIPfad\fP kann zur Verbindung der Standardeingabe mit einem bestimmten Dateisystemobjekt verwandt werden\&. Es wird ein absoluter Pfad gefolgt von dem Zeichen »:« erwartet, der sich auf eine reguläre Datei, ein FIFO oder eine Spezialdatei beziehen kann\&. Falls ein \fBAF_UNIX\fP\-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\&. .sp Die Option »\fBsocket\fP« ist nur in Socket\-aktivierten Diensten gültig und es muss in der relevanten Socket\-Unit\-Datei (siehe \fBsystemd.socket\fP(5) für Details) \fIAccept=yes\fP gesetzt oder nur ein einzelnes Socket spezifiziert sein\&. Falls diese Option gesetzt ist, wird die Standardeingabe mit dem Socket, aus dem der Dienst aktiviert wurde, verbunden\&. Dies ist hauptsächlich für die Kompatibilität mit Daemons nützlich, die für die Verwendung mit der traditionellen \fBinetd\fP(8)\-Socket\-Daemon\-Aktivierung entwickelt wurden\&. .sp Die Option \fBfd:\fP\fIName\fP verbindet die Standardeingabe mit einem durch die Socket\-Unit bereitgestellten bestimmten, benannten Dateideskriptor\&. Der Name kann als Teil dieser Option 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 \fISockets=\fP bereitgestellt werden und der Dateideskriptorname darf sich vom Namen der Socket\-Unit, die ihn enthält, unterscheiden\&. Falls mehrere Treffer gefunden werden, wird der erste verwandt\&. Siehe \fIFileDescriptorName=\fP in \fBsystemd.socket\fP(5) für weitere Details über benannte Dateideskriptoren und ihrer Sortierung\&. .sp Diese Einstellung ist standardmäßig \fBnull\fP\&. .RE .PP \fIStandardOutput=\fP .RS 4 Steuert, womit der Dateideskriptor 1 (Stdout) des ausgeführten Prozesses verbunden ist\&. Akzeptiert entweder \fBinherit\fP, \fBnull\fP, \fBtty\fP, \fBjournal\fP, \fBkmsg\fP, \fBjournal+console\fP, \fBkmsg+console\fP, \fBfile:\fP\fIPfad\fP, \fBappend:\fP\fIPfad\fP, \fBsocket\fP oder \fBfd:\fP\fIName\fP\&. .sp \fBinherit\fP dupliziert den Dateideskriptor der Standardeingabe für die Standardausgabe\&. .sp \fBnull\fP verbindet die Standardausgabe mit /dev/null, d\&.h\&. alles dahin Geschriebene geht verloren\&. .sp \fBtty\fP verbindet die Standardausgabe mit einem TTY (wie in \fITTYPath=\fP konfiguriert, siehe unten)\&. Falls das TTY nur für die Ausgabe verwandt wird, wird der ausgeführte Prozess nicht der steuernde Prozess des Terminals werden und wird nicht fehlschlagen oder darauf warten, dass andere Prozesse das Terminal freigeben\&. .sp \fBjournal\fP verbindet die Standardausgabe mit dem Journal, das über \fBjournalctl\fP(1) erreichbar ist\&. Beachten Sie, dass alles, was nach Syslog oder Kmsg (siehe unten) geschrieben wird, implizit auch im Journal gespeichert wird, die 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\&.) .sp \fBkmsg\fP verbindet die Standardeingabe mit dem Kernelprotokollpuffer, der über \fBdmesg\fP(1) erreichbar ist, zusätzlich zum Journal\&. Der Journal\-Daemon könnte so konfiguriert sein, dass er alles, was er empfängt, sowieso zu Kmsg sendet, wodurch diese Option in diesem Fall keinen Unterschied zu \fBjournal\fP darstellt\&. .sp \fBjournal+console\fP und \fBkmsg+console\fP arbeiten auf eine ähnliche Art wie die zwei Optionen oben, kopieren aber auch sämtliche Ausgabe auf die Systemkonsole\&. .sp Die Option \fBfile:\fP\fIPfad\fP kann zum Verbinden eines bestimmten Dateisystemobjektes mit der Standardausgabe verwandt werden\&. Die Semantik ist ähnlich zu der der gleichen Option von \fIStandardInput=\fP, siehe oben\&. Falls sich \fIPfad\fP auf eine reguläre Datei auf dem Dateisystem bezieht, wird sie zum Schreiben am Anfang der Datei geöffnet (erstellt, falls sie noch nicht existiert), aber ohne sie abzuschneiden\&. Falls die Standardeingabe und \-ausgabe auf den gleichen Dateipfad verwiesen werden, wird dieser nur einmal zum Lesen und Schreiben geöffnet und dupliziert\&. Dies ist insbesondere nützlich, wenn sich der festgelegte Pfad auf ein \fBAF_UNIX\fP\-Socket im Dateisystem bezieht, da in diesem Fall nur eine einzelne Datenstromverbindung für sowohl Ein\- als auch Ausgabe erstellt wird\&. .sp \fBappend:\fP\fIPfad\fP ist ähnlich zu \fBfile:\fP\fIPfad\fP oben, es öffnet die Datei aber im Anhängemodus\&. .sp \fBsocket\fP verbindet die Standardausgabe zu einem mittels Socket\-Aktivierung erlangten Socket\&. Die Semantik ist ähnlich zu der der gleichen Option von \fIStandardInput=\fP, siehe oben\&. .sp Die Option \fBfd:\fP\fIName\fP verbindet die Standardausgabe mit einem bestimmten benannten, durch eine Socket\-Unit bereitgestellten Dateideskriptor\&. Es kann als Teil dieser Option ein Name, gefolgt von einem »:«\-Zeichen, 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 \fISockets=\fP bereitgestellt werden und der Dateideskriptorname darf sich vom Namen der Socket\-Unit, die ihn enthält, unterscheiden\&. Falls mehrere Treffer gefunden werden, wird der erste verwandt\&. Siehe \fIFileDescriptorName=\fP in \fBsystemd.socket\fP(5) für weitere Details über benannte Dateideskriptoren und ihrer Sortierung\&. .sp Falls die Standardausgabe (oder die Fehlerausgabe, siehe unten) einer Unit mit dem Journal oder dem Kernelprotokollpuffer verbunden ist, wird die Unit implizit eine Abhängigkeit vom Typ \fIAfter=\fP von systemd\-journald\&.socket erhalten (siehe auch den Abschnitt »Implizite Abhängigkeiten« oben)\&. Beachten Sie auch, dass in diesem Fall Stdout (oder Stderr, siehe unten) ein \fBAF_UNIX\fP\-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 »\fBecho "hello" > /dev/stderr\fP« zum Schreiben von Text nach Stderr nicht funktionieren wird\&. Um dies zu entschärfen, verwenden Sie stattdessen die Konstruktion »\fBecho "hello" >&2\fP«, die größtenteils äquivalent ist und diesen Fallstrick vermeidet\&. .sp Der Vorgabewert dieser Einstellung ist der mit \fIDefaultStandardOutput=\fP in \fBsystemd\-system.conf\fP(5) gesetzte Wert, der standardmäßig \fBjournal\fP ist\&. Beachten Sie, dass dieser Parameter zum Hinzufügen zusätzlicher Abhängigkeiten führen kann (siehe oben)\&. .RE .PP \fIStandardError=\fP .RS 4 Steuert, womit Dateideskriptor 2 (Stderr) des ausgeführten Prozesses verbunden ist\&. Die verfügbaren Optionen sind identisch zu denen von \fIStandardOutput=\fP mit einigen Ausnahmen: falls auf \fBinherit\fP gesetzt, wird der für die Standardausgabe verwandte Dateideskriptor für die Standardfehlerausgabe dupliziert, während \fBfd:\fP\fIName\fP den vorgegebenen Dateideskriptornamen von »stderr« verwenden wird\&. .sp Der Vorgabewert dieser Einstellung ist der mit \fIDefaultStandardError=\fP in \fBsystemd\-system.conf\fP(5) gesetzte Wert, der standardmäßig \fBinherit\fP ist\&. Beachten Sie, dass dieser Parameter zum Hinzufügen zusätzlicher Abhängigkeiten führen kann (siehe oben)\&. .RE .PP \fIStandardInputText=\fP, \fIStandardInputData=\fP .RS 4 Konfiguriert beliebige textuelle oder binäre Daten, die mittels Dateideskriptor 0 (STDIN) an den ausgeführten Prozess übergeben werden sollen\&. Diese Einstellung hat keine Wirkung, außer \fIStandardInput=\fP ist auf \fBdata\fP gesetzt\&. Verwenden Sie diese Option, um Prozesseingabedaten direkt in die Unit\-Datei einzubetten\&. .sp \fIStandardInputText=\fP akzeptiert beliebige textuelle Daten\&. C\-artige Maskierungen für besondere Zeichen sowie die normalen »%«\-Kennzeichner werden aufgelöst\&. Jedes Mal, wenn diese Einstellung benutzt wird, wird der festgelegte Text an den Unit\-bezogenen Datenpuffer, gefolgt von einem Zeilenumbruchzeichen, angehängt (daher hängt jeder Einsatz eine neue Zeile an das Ende des Puffers an)\&. Beachten Sie, dass einleitende und abschließende Leerraumzeichen von mit dieser Option konfigurierten Zeilen entfernt werden\&. Falls eine leere Zeile festgelegt wird, wird der Puffer bereinigt (daher sollte ein zusätzliches »\en« an das Ende oder den Anfang einer Zeile eingefügt werden, um eine leere Zeile einzufügen)\&. .sp \fIStandardInputData=\fP akzeptiert beliebige, in \m[blue]\fBBase64\fP\m[]\&\s-2\u[9]\d\s+2 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\&. .sp Beachten Sie, dass \fIStandardInputText=\fP und \fIStandardInputData=\fP auf dem gleichen Datenpuffer arbeiten und gemischt werden können, um sowohl binäre als auch textuelle Daten für den gleichen Eingabedatenstrom zu konfigurieren\&. Die textuellen oder binären Daten werden genau in der Reihenfolge zusammengefügt, in der sie in der Unit\-Datei auftauchen\&. Wird einem eine leere Zeichenkette zugewiesen, wird der Datenpuffer zurückgesetzt\&. .sp Bitte beachten Sie, dass lange Unit\-Dateieinstellungen in mehrere Zeilen aufgeteilt werden können, um die Lesbarkeit zu erhalten\&. Hierzu wird jeder Zeile (außer der letzten) ein Zeichen »\e« vorangestellt (siehe \fBsystemd.unit\fP(5) für Details)\&. Dies ist insbesondere für große Daten, die mit diesen Optionen konfiguriert werden, nützlich\&. Beispiel: .sp .if n \{\ .RS 4 .\} .nf … StandardInput=data StandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl \e LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \e dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug \e enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \e SWNrZSEK … .fi .if n \{\ .RE .\} .RE .PP \fILogLevelMax=\fP .RS 4 Konfiguriert eine Filterung gemäß Protokollierstufe der durch diese Unit erstellten Protokollnachrichten\&. Akzeptiert eine \fBsyslog\fP\-Protokollstufe, entweder \fBemerg\fP (niedrigste Protokollierstufe, nur Nachrichten höchster Priorität), \fBalert\fP, \fBcrit\fP, \fBerr\fP, \fBwarning\fP, \fBnotice\fP, \fBinfo\fP oder \fBdebug\fP (höchste Protokollierstufe, auch Nachrichten niedrigster Priorität)\&. Siehe \fBsyslog\fP(3) für Details\&. Standardmäßig wird keine Filterung angewandt (d\&.h\&. die maximale Protokollierstufe ist standardmäßig \fBdebug\fP)\&. Verwenden Sie diese Option, um das Protokolliersystem zu konfigurieren, damit es Protokollnachrichten eines bestimmten Dienstes oberhalb der festgelegten Stufe verwirft\&. Setzen Sie beispielsweise \fILogLevelMax=\fP\fBinfo\fP, um die Fehlersuchprotokollierung eines bestimmten, gesprächigen Dienstes auszuschalten\&. Beachten Sie, dass die konfigurierte Stufe auf alle versandten Protokollnachrichten aller zu diesem Dienst gehörenden Prozesse auf allen unterstützten Protokollierungsprotokollen angewandt wird\&. Die Filterung erfolgt frühzeitig in der Protokollierungspipeline, bevor jegliche Art weiterer Verarbeitung erfolgt\&. Desweiteren könnten Nachrichten, die erfolgreich durch diesen Filter kommen, dennoch durch angewandte Filter in einer späteren Stufe im Protokollierungsuntersystem verworfen werden\&. Beispielsweise könnte ein in \fBjournald.conf\fP(5) konfiguriertes \fIMaxLevelStore=\fP verbieten, Nachrichten von höheren Protokollierstufen auf Platte zu speichen, selbst wenn das Unit\-bezogene \fILogLevelMax=\fP die Verarbeitung erlaubte\&. .RE .PP \fILogExtraFields=\fP .RS 4 Konfiguriert zusätzliche Protokollmetadatenfelder, die in alle Protokolldatensätze aufgenommen werden, die von Prozessen, die dieser Unit zugeordnet sind, erstellt werden\&. Diese Einstellung akzeptiert eine oder mehrere Journal\-Feldzuweisungen im Format »FELD=WERT«, getrennt durch Leerraumzeichen\&. Siehe \fBsystemd.journal\-fields\fP(7) für Details zum Journal\-Feldkonzept\&. Obwohl die zugrundeliegende Journal\-Implementierung binäre Feldnamen erlaubt, akzeptiert diese Einstellung nur gültige UTF\-8\-Werte\&. Um Leerzeichen in einem Journal\-Feldwert aufzunehmen, schließen Sie die Zuweisung in doppelte Anführungszeichen (") ein\&. Die normalen Kennzeichner werden in allen Zuweisungen expandiert (siehe unten)\&. Beachten Sie, dass diese Einstellung nicht nur für das Anhängen von zusätzlichen Metadaten an Protokolldatensätzen einer Unit nützlich ist\&. Da alle Felder und Werte indiziert sind, kann dies auch für Unit\-übergreifenden Protokolldatensatzabgleich verwandt werden\&. Wird eine leere Zeichenkette zugewiesen, wird die Liste zurückgesetzt\&. .RE .PP \fILogRateLimitIntervalSec=\fP, \fILogRateLimitBurst=\fP .RS 4 Konfiguriert die Ratenbegrenzung, die auf von dieser Unit erstellte Nachrichten angewandt wird\&. Falls in dem durch \fILogRateLimitIntervalSec=\fP definierten Intervall mehr als in \fILogRateLimitBurst=\fP festgelegte Nachrichten durch den Dienst protokolliert werden, werden alle weiteren Nachrichten in dem Intervall verworfen, bis das Intervall vorüber ist\&. Es wird eine Meldung über die verworfenen Nachrichten erstellt\&. Die Zeitspezifikation für \fILogRateLimitIntervalSec=\fP kann in einer der folgenden Einheiten erfolgen: »s«, »min«, »h«, »ms«, »us« (siehe \fBsystemd.time\fP(7) für Details)\&. Die Voreinstellungen erfolgen durch die in \fBjournald.conf\fP(5) konfigurierten \fIRateLimitIntervalSec=\fP und \fIRateLimitBurst=\fP\&. .RE .PP \fILogNamespace=\fP .RS 4 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 Protkolldaten (unabhängig, ob diese mittels \fBsyslog()\fP, 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 \fBsystemd\-journald.service\fP(8) für Details über Journal\-Namensräume\&. .sp Intern sind Journal\-Namensräume mittes Linux\-Einhängenamensräume und durch Übereinhängen des Verzeichnisses, das die relevanten \fBAF_UNIX\fP\-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 \fIReadOnlyPaths=\fP und ähnliche Einstellungen (siehe oben) funktionieren\&. Journal\-Namensräume können daher nicht für Dienste verwandt werden, die Einhängepunkte auf dem Rechner etablieren müssen\&. .sp 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 \fBjournalctl\fP(1)\-Ausgabe erscheint, außer die Option \fB\-\-namespace=\fP wird verwandt\&. .sp Diese Option ist nur für Systemdienste verfügbar und wird nicht für Dienste, die in benutzerbezogenene Instanzen des Diensteverwalters laufen, unterstützt\&. .RE .PP \fISyslogIdentifier=\fP .RS 4 Setzt den Prozessnamen (»\fBsyslog\fP\-Markierung«), der allen an das Protokollierungssystem oder den Kernelpuffer gesandten langen Zeilen vorangestellt werden soll\&. Falls nicht gesetzt, ist die Vorgabe der Prozessname des ausgeführten Prozesses\&. Diese Option ist nur nützlich, wenn \fIStandardOutput=\fP oder \fIStandardError=\fP auf \fBjournal\fP oder \fBkmsg\fP gesetzt ist (oder die gleichen Einstellungen in Kombination mit \fB+console\fP)\&. Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden, angewandt\&. .RE .PP \fISyslogFacility=\fP .RS 4 Setzt den \fBsyslog\fP\-Einrichtungskennzeichner, der beim Protokollieren verwandt werden soll\&. Entweder \fBkern\fP, \fBuser\fP, \fBmail\fP, \fBdaemon\fP, \fBauth\fP, \fBsyslog\fP, \fBlpr\fP, \fBnews\fP, \fBuucp\fP, \fBcron\fP, \fBauthpriv\fP, \fBftp\fP, \fBlocal0\fP, \fBlocal1\fP, \fBlocal2\fP, \fBlocal3\fP, \fBlocal4\fP, \fBlocal5\fP, \fBlocal6\fP oder \fBlocal7\fP\&. Siehe \fBsyslog\fP(3) für Details\&. Diese Option ist nur nützlich, wenn \fIStandardOutput=\fP oder \fIStandardError=\fP auf \fBjournal\fP oder \fBkmsg\fP gesetzt ist (oder die gleichen Einstellungen in Kombination mit \fB+console\fP)\&. Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden, angewandt\&. Standardmäßig \fBdaemon\fP\&. .RE .PP \fISyslogLevel=\fP .RS 4 Die Vorgabe\-\fBsyslog\fP\-Protokollierstufe, die beim Protokollieren zum Protokollierungssystem oder Kernelprotokollpuffer verwandt werden soll\&. Entweder \fBemerg\fP, \fBalert\fP, \fBcrit\fP, \fBerr\fP, \fBwarning\fP, \fBnotice\fP, \fBinfo\fP oder \fBdebug\fP\&. Siehe \fBsyslog\fP(3) für Details\&. Diese Option ist nur nützlich, wenn \fIStandardOutput=\fP oder \fIStandardError=\fP auf \fBjournal\fP oder \fBkmsg\fP gesetzt ist (oder die gleichen Einstellungen in Kombination mit \fB+console\fP)\&. Sie wird nur auf Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden, angewandt\&. Beachten Sie, dass individuellen Zeilen, die von ausgeführten Prozessen ausgegeben werden, eine andere Protokollierungsstufe vorangestellt werden kann, die dazu verwandt werden kann, die hier festgelegte Vorgabeprotokollstufe außer Kraft zu setzen\&. Die Auswertung dieser vorangestellten Werte kann mit \fISyslogLevelPrefix=\fP deaktiviert werden, siehe unten\&. Für Details siehe \fBsd\-daemon\fP(3)\&. Standardmäßig \fBinfo\fP\&. .RE .PP \fISyslogLevelPrefix=\fP .RS 4 Akzeptiert ein logisches Argument\&. Falls wahr und \fIStandardOutput=\fP oder \fIStandardError=\fP auf \fBjournal\fP oder \fBkmsg\fP gesetzt ist (oder die gleichen Einstellungen in Kombination mit \fB+console\fP), wird Protokollzeilen, die durch die ausgeführten Prozesse geschrieben werden, denen eine Protokollierungsstufe vorangestellt ist, verarbeitet, wobei die vorangestellte Protokollierungsstufe entfernt wird\&. Falls auf falsch gesetzt, wird die Auswertung dieser vorangestellten Werte deaktiviert und die protokollierten Zeilen unverändert weitergegeben\&. Dies gilt nur für Protokollnachrichten, die nach Stdout oder Stderr geschrieben werden\&. Für Details bezüglich des Voranstellens siehe \fBsd\-daemon\fP(3)\&. Standardmäßig wahr\&. .RE .PP \fITTYPath=\fP .RS 4 Setzt den zu verwendenden Terminalgeräteknoten, falls die Standardeingabe, \-ausgabe oder \-fehlerausgabe mit einem TTY verbunden ist (siehe oben)\&. Standardmäßig /dev/console\&. .RE .PP \fITTYReset=\fP .RS 4 Setzt das mit \fITTYPath=\fP festgelegte Terminalgerät vor und nach der Ausführung zurück\&. Standardmäßig »no«\&. .RE .PP \fITTYVHangup=\fP .RS 4 Trennt alle Clients, die das mit \fITTYPath=\fP festgelegte Terminalgerät vor und nach der Ausführung geöffnet haben\&. Standardmäßig »no«\&. .RE .PP \fITTYVTDisallocate=\fP .RS 4 Falls das mit \fITTYPath=\fP 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«\&. .RE .SH ZUGANGSDATEN .PP \fILoadCredential=\fP\fIKENNUNG\fP:\fIPFAD\fP .RS 4 Übergibt ein Zugangsdatum an die Unit\&. Zugangsdaten sind binäre oder textuelle Objekte begrenzter Größe, die an Prozesse von Units übergeben werden können\&. Sie werden hauptsächlich zur Weitergabe kryptographischer Schlüssel (sowohl öffentlicher als auch privater) oder Zertifikaten, Benutzerkontoinformationen oder Identitätsinformationen vom Rechner an Dienste verwandt\&. Von den Prozessen der Unit kann auf diese Daten mittels des Dateisystems zugegriffen werden, an einem rein lesbaren Ort der (falls möglich und erlaubt) durch Speicher, der nicht ausgelagert werden darf, hinterlegt ist\&. Auf die Daten kann nur durch den Benutzer, der der Unit über die Einstellung \fIUser=\fP/\fIDynamicUser=\fP zugeordnet ist, zugegriffen werden (sowie dem Systemverwalter)\&. Wenn verfügbar, wird der Ort der Zugangsdaten in der Umgebungsvariable \fI$CREDENTIALS_DIRECTORY\fP für die Prozesse der Unit exportiert\&. .sp Die Einstellung \fILoadCredential=\fP akzeptiert eine textuelle Kennung als Namen für ein Zugangsdatum sowie einen Dateisystempfad\&. Die Kennung muss eine kurze ASCII\-Zeichenkette sein, die als Dateiname in dem Dateisystem geeignet ist, und kann vom Benutzer frei gewählt werden\&. Falls der angegebene Pfad absolut ist, wird er als reguläre Datei geöffnet und das Zugangsdatum wird daraus gelesen\&. Falls sich der absolute Pfad auf ein \fBAF_UNIX\fP\-Datenstrom\-Socket im Dateisystem bezieht, dann wird zu ihm eine Verbindung aufgebaut (nur einmalig während des Startens) und das Zugangsdatum aus dieser Verbindung ausgelesen, wodurch ein einfacher IPC\-Integrationspunkt bereitgestellt wird, um Zugangsdaten dynamisch von anderen Diensten bereitzustellen\&. Falls der angegeben Pfad nicht absolut ist und selbst wieder als gültiger Zugangsdatumkennzeichner geeignet ist, wird er so interpretiert, dass er sich auf ein Zugangsdatum bezieht, das der Diensteverwalter selbst mittels der Umgebungsvariable \fI$CREDENTIALS_DIRECTORY\fP empfangen hat, was zur Weiterleitung von Zugangsdaten von einer aufrufenden Umgebung (z\&.B\&. einem Container\-Verwalter, der den Diensteverwalter aufgerufen hat) an einen Dienst verwandt werden kann\&. Der Inhalt der Datei/des Sockets können beliebige binäre oder textuelle Daten sein, einschließlich Zeilenumbruchzeichen und \fBNUL\fP\-Bytes\&. Diese Option kann mehrfach verwandt werden, wobei jedes Mal ein zusätzliches Zugangsdatum definiert wird, das an die Unit übergeben wird\&. .sp Der Diensteverwalter muss auf die Zugangsdaten\-Dateien/\-Sockets zugreifen können, aber die Prozesse müsse nicht direkt darauf zugreifen können: die Zugangsdaten werden gelesen und getrennte, nur lesbare Kopien für die Unit werden angelegt, die von den geeignet privilegierten Prozessen gelesen werden können\&. Dies ist insbesondere in Kombination mit \fIDynamicUser=\fP nützlich, da auf diese Art privilegierte Daten für Prozesse zur Verfügung gestellt werden können, die unter einer dynamischen UID laufen (d\&.h\&. einer bisher nicht bekannten), ohne den Zugriff für alle Benutzer zu eröffnen\&. .sp Um innerhalb einer \fIExecStart=\fP\-Befehlszeile einen Pfad zu referenzieren, unter dem ein Zugangsdatum gelesen werden kann, verwenden Sie »${CREDENTIALS_DIRECTORY}/mycred«, z\&.B\&. »ExecStart=cat ${CREDENTIALS_DIRECTORY}/mycred«\&. .sp Derzeit wird eine Größenbegrenzung für aufsummierte Zugangsdaten von 1 MB pro Unit durchgesetzt\&. .sp Wird auf ein \fBAF_UNIX\fP\-Datenstrom\-Socket für die Verbindung referenziert, dann wird der Ursprung der Verbindung in einem abstrakten Namensraum\-Socket liegen, der Informationen über die Unit und die Zugangsdatenkennung in seinem Socket\-Namen enthält\&. Verwenden Sie \fBgetpeername\fP(2), um diese Information abzufragen\&. Der zurückgelieferte Socket\-Name ist als \fBNUL\fP \fIZUFALL\fP »unit« \fIUNIT\fP »/« \fIKENNUNG\fP formatiert, d\&.h\&. ein \fBNUL\fP\-Byte (wie für Socket\-Namen aus abstrakten Namensräumen benötigt), gefolgt von einer zufälligen Zeichenkette (die aus alphadezimalen Zeichen besteht), gefolgt von der Zeichenkette »unit«, gefolgt von dem anfragenden Unit\-Namen, gefolgt von dem Zeichen »/«, gefolgt von der erbetenen textuellen Zugangsdatenkennung\&. Beispiel: »\e0adf9d86b6eda275e/unit/foobar\&.service/credx«, wobei die Zugangsdaten »credx« für eine Unit »foobar\&.service« erbeten werden\&. Diese Funktionalität ist nützlich, wenn ein einzelnes, auf Anfragen wartendes Socket Zugangsdaten für mehrere Abnehmer bereitstellen soll\&. .RE .PP \fISetCredential=\fP\fIKENNUNG\fP:\fIWERT\fP .RS 4 Die Einstellung \fISetCredential=\fP ist ähnlich zu \fILoadCredential=\fP, akzeptiert aber einen buchstäblichen Wert, der als Daten für die Zugangsdaten verwandt werden soll, statt eines Dateisystempfades, aus dem die Daten gelesen werden sollen\&. Verwenden Sie diese Option nicht für Daten, die geheim gehalten werden sollen, da nicht privilegierte Benutzer darauf mittels IPC zugreifen können\&. Es ist nur sicher, dies für Benutzerkennungen, öffentliches Schlüsselmaterial und ähnliche, nicht sensiblen Daten zu verwenden\&. Verwenden Sie für alles andere \fILoadCredential=\fP\&. Um binäre Daten in die Zugangsdaten einzubetten, verwenden Sie C\-artige Maskierungen (d\&.h\&. »\en«, um einen Zeilenumbruch einzubetten oder »\ex00«, um ein \fBNUL\fP\-Byte einzubetten)\&. .sp Falls ein Zugangsdatum mit der gleichen Kennung sowohl in \fILoadCredential=\fP als auch in \fISetCredential=\fP aufgeführt ist, dann wird letzteres als Vorgabe agieren, falls ersteres nicht abgefragt werden kann\&. In diesem Fall wird der Fehlschlag, das in \fILoadCredential=\fP festgelegte Zugangsdatum nicht abfragen zu können, nicht als fatal betrachtet\&. .RE .SH "SYSTEM V\-KOMPATIBILITÄT" .PP \fIUtmpIdentifier=\fP .RS 4 Akzeptiert eine Kennzeichnungszeichenkette aus vier Zeichen für einen \fButmp\fP(5)\- und Wtmp\-Eintrag für diesen Dienst\&. Dies sollte nur für Dienste wie \fBgetty\fP\-Implementierungen (wie \fBagetty\fP(8)) gesetzt werden, bei denen Utmp/Wtmp\-Einträge erstellt und vor und nach der Ausführung bereinigt werden müssen oder für Dienste, die so ausgeführt werden sollen, als ob sie durch einen \fBgetty\fP\-Prozess ausgeführt würden (siehe unten)\&. Falls die Konfigurationszeichenkette länger als vier Zeichen ist, wird sie gekürzt und die vier Zeichen am Ende werden verwandt\&. Diese Einstellung interpretiert %I\-artige Zeichenkettenersetzungen\&. Diese Einstellung ist standardmäßig nicht gesetzt, d\&.h\&. dass für diesen Dienst keine Utmp\-/Wtmp\-Einträge erstellt oder bereinigt werden\&. .RE .PP \fIUtmpMode=\fP .RS 4 Akzeptiert entweder »init«, »login« oder »user«\&. Falls \fIUtmpIdentifier=\fP gesetzt ist, steuert dies die Art der für diesen Dienst erstellten \fButmp\fP(5)/wtmp\-Einträge\&. Diese Einstellung ist wirkungslos, außer \fIUtmpIdentifier=\fP ist auch gesetzt\&. Falls »init« gesetzt ist, wird nur ein \fBINIT_PROCESS\fP\-Eintrag erstellt und der aufgerufene Prozess muss eine \fBgetty\fP\-kompatible Utmp/Wtmp\-Logik implementieren\&. Falls »login« gesetzt ist, wird zuerst ein \fBINIT_PROCESS\fP\-Eintrag, gefolgt von einem \fBLOGIN_PROCESS\fP\-Eintrag erstellt\&. In diesem Fall muss der aufgerufene Prozess eine \fBlogin\fP(1)\-kompatible Utmp/Wtmp\-Logik implementieren\&. Falls »user« festgelegt ist, wird zuerst ein \fBINIT_PROCESS\fP\-Eintrag, dann ein \fBLOGIN_PROCESS\fP\-Eintrag und schließlich ein \fBUSER_PROCESS\fP\-Eintrag erstellt\&. In diesem Fall kann der Prozess jeder Prozess sein, der zum Betrieb als Sitzungsleiter geeignet ist\&. Standardmäßig »init«\&. .RE .SH "UMGEBUNGSVARIABLEN IN ERZEUGTEN PROZESSEN" .PP Durch den Diensteverwalter gestartete Prozesse werden mit einem Umgebungsvariablenblock gestartet, der aus verschiedenen Quellen zusammengesetzt ist\&. Prozesse, die durch den Systemdiensteverwalter gestartet werden, erben im Allgemeinen die für den Diensteverwalter selbst gesetzten Umgebungsvariablen nicht (dies kann durch \fIPassEnvironment=\fP geändert werden), aber Prozesse, die durch Benutzerdiensteverwalterinstanzen gestartet werden, erben im Allgemein alle für den Diensteverwalter selbst gesetzten Umgebungsvariablen\&. .PP Für jeden aufgerufenen Prozess wird die Liste der gesetzten Umgebungsvariablen aus den folgenden Quellen zusammengestellt: .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Variablen, die global für den Diensteverwalter mittels der Einstellung \fIDefaultEnvironment=\fP in \fBsystemd\-system.conf\fP(5), der Kernelbefehlszeilenoption \fIsystemd\&.setenv=\fP von \fBsystemd\fP(1) verstanden werden oder mittels des Unterbefehls \fBset\-environment\fP von \fBsystemctl\fP gesetzt werden\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Durch den Diensteverwalter selbst definierte Variablen (siehe nachfolgende Liste)\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Variablen, die durch den Umgebungsvariablenblock des Diensteverwalters selbst gesetzt sind (abhängig von \fIPassEnvironment=\fP für den Systemdiensteverwalter)\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Mittels \fIEnvironment=\fP in der Unit\-Datei gesetzte Variablen\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Aus mit \fIEnvironmentFile=\fP in der Unit\-Datei festgelegten Dateien gelesene Variablen\&. .RE .sp .RS 4 .ie n \{\ \h'-04'\(bu\h'+03'\c .\} .el \{\ .sp -1 .IP \(bu 2.3 .\} Falls \fIPAMName=\fP wirksam ist, siehe \fBpam_env\fP(8), durch alle PAM\-Module gesetzte Variablen\&. .RE .PP Falls die gleiche Umgebungsvariable aus mehreren dieser Quellen gesetzt wird, gewinnt die letzte Quelle, wobei die Reihenfolge der obigen Liste zählt\&. Beachten Sie, dass als abschließender Schritt alle in \fIUnsetEnvironment=\fP aufgeführten Variablen aus der zusammengestellten Variablenliste entfernt werden, direkt bevor sie an den ausgeführten Prozess übergeben wird\&. .PP Die allgemeine Philosphie ist, Prozessen eine kleine, gepflegte Liste von Umgebungsvariablen offenzulegen\&. Vom Diensteverwalter (PID 1) gestartete Dienste werden ohne zusätzliche Dienste\-spezifische Konfiguration und mit nur ein paar Umgebungsvariablen gestartet\&. Der Benutzerverwalter erbt Umgebungsvariablen wie jeder andere Systemdienst, kann aber ein paar zusätzliche Umgebungsvariablen von PAM und typischerweise zusätzliche importierte Variablen, wenn der Benutzer eine graphische Sitzung startet, empfangen\&. Es wird empfohlen, die Umgebungsblöcke sowohl im System\- als auch in Benutzerverwaltern schlank zu halten\&. .PP Tipp: \fBsystemd\-run \-P env\fP und \fBsystemd\-run \-\-user \-P env\fP geben die wirksamen System\- und Benutzerdiensteverwalter\-Umgebungsblöcke aus\&. .SS "Vom Diensteverwalter gesetzte oder ausgebreitete Umgebungsvariablen" .PP Die folgenden Umgebungsvariablen werden für jeden durch den Diensteverwalter aufgerufenen Prozess ausgebreitet oder intern erstellt: .PP \fI$PATH\fP .RS 4 Doppelpunkt\-getrennte Liste von Verzeichnissen, die beim Starten von Programmen verwandt werden\&. \fBsystemd\fP verwendet einen festgelegten Wert von »/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin« im Systemverwalter\&. Wird dies auf Systemen mit »nicht zusammengeführtem /usr/« (/bin ist kein Symlink auf /usr/bin) kompiliert, wird »:/sbin:/bin« angehängt\&. Im Falle des Benutzerverwalters kann durch die Distribution ein anderer Pfad konfiguriert sein\&. Es wird empfohlen, sich auf die Reihenfolge der Einträge nicht zu verlassen, und nur ein Programm mit einem vorgegebenen Namen in \fI$PATH\fP zu haben\&. .RE .PP \fI$LANG\fP .RS 4 Locale\&. Kann in \fBlocale.conf\fP(5) oder auf der Kernelbefehlszeile gesetzt werden (siehe \fBsystemd\fP(1) und \fBkernel\-command\-line\fP(7))\&. .RE .PP \fI$USER\fP, \fI$LOGNAME\fP, \fI$HOME\fP, \fI$SHELL\fP .RS 4 Benutzername (zweifach), Home\-Verzeichnis und die Anmelde\-Shell\&. Die Variablen sind für die Units, die \fIUser=\fP gesetzt haben, gesetzt, dazu gehören Benutzer\-\fBsystemd\fP\-Instanzen\&. Siehe \fBpasswd\fP(5)\&. .RE .PP \fI$INVOCATION_ID\fP .RS 4 Enthält eine zufällige, eindeutige, 128\-Bit\-Kennzeichnung, die jeden Laufzeitzyklus der Unit identifiziert\&. Sie ist als hexadezimale Zeichenkette mit 32 Zeichen formatiert\&. Jedes Mal, wenn die Unit sich vom inaktiven Zustand in einen aktivierenden oder aktiven Zustand ändert, wird eine neue Kennung zugewiesen\&. Sie kann zur Kennzeichnung dieses bestimmten Laufzeitzyklus verwandt werden, insbesondere in gespeicherten Daten wie dem Journal\&. Die gleiche Kennung wird an alle als Teil der Unit ausgeführten Prozesse übergeben\&. .RE .PP \fI$XDG_RUNTIME_DIR\fP .RS 4 Das Verzeichnis, das für Laufzeitobjekte (wie IPC\-Objekte) und flüchtige Zustände verwandt werden soll\&. Wird für alle von der Benutzer\-\fBsystemd\fP\-Instanz ausgeführten Prozesse sowie von allen Systemdiensten, die \fIPAMName=\fP mit einem PAM\-Stack, der \fBpam_systemd\fP enthält, verwandt wird, gesetzt\&. Siehe unten und \fBpam_systemd\fP(8) für weitere Informationen\&. .RE .PP \fI$RUNTIME_DIRECTORY\fP, \fI$STATE_DIRECTORY\fP, \fI$CACHE_DIRECTORY\fP, \fI$LOGS_DIRECTORY\fP, \fI$CONFIGURATION_DIRECTORY\fP .RS 4 Absolute Pfade zu den in \fIRuntimeDirectory=\fP, \fIStateDirectory=\fP, \fICacheDirectory=\fP, \fILogsDirectory=\fP und \fIConfigurationDirectory=\fP definierten Verzeichnissen, wenn diese Einstellungen verwandt werden\&. .RE .PP \fI$CREDENTIALS_DIRECTORY\fP .RS 4 Ein absoluter Pfad zu einem Unit\-spezifischen Verzeichnis mit Zugangsdaten, die mittels \fILoadCredential=\fP/\fISetCredential=\fP konfiguriert wurden\&. Das Verzeichnis ist als rein lesbar markiert und auf nicht auslagerbaren Speicher abgelegt (falls unterstützt und erlaubt) und kann nur von der UID aus zugegriffen werden, die der Unit via \fIUser=\fP oder \fIDynamicUser=\fP zugeordnet ist (und dem Systemverwalter)\&. .RE .PP \fI$MAINPID\fP .RS 4 Die PID des Hauptprozesses der Unit, falls bekannt\&. Dies wird nur für durch \fIExecReload=\fP und Ähnliches aufgerufene Steuerprozesse gesetzt\&. .RE .PP \fI$MANAGERPID\fP .RS 4 Die PID der Benutzer\-\fBsystemd\fP\-Instanz, gesetzt für davon erzeugte Prozesse\&. .RE .PP \fI$LISTEN_FDS\fP, \fI$LISTEN_PID\fP, \fI$LISTEN_FDNAMES\fP .RS 4 Informationen über Dateideskriptoren, die an einen Dienst für Socket\-Aktivierung weitergegeben wurden\&. Siehe \fBsd_listen_fds\fP(3)\&. .RE .PP \fI$NOTIFY_SOCKET\fP .RS 4 Das Socket, mit dem \fBsd_notify()\fP kommuniziert\&. Siehe \fBsd_notify\fP(3)\&. .RE .PP \fI$WATCHDOG_PID\fP, \fI$WATCHDOG_USEC\fP .RS 4 Informationen über Watchdog\-Aufrechterhaltungsbenachrichtigungen\&. Siehe \fBsd_watchdog_enabled\fP(3)\&. .RE .PP \fI$TERM\fP .RS 4 Terminaltyp, nur für mit einem Terminal verbundene Units gesetzt (\fIStandardInput=tty\fP, \fIStandardOutput=tty\fP oder \fIStandardError=tty\fP)\&. Siehe \fBtermcap\fP(5)\&. .RE .PP \fI$LOG_NAMESPACE\fP .RS 4 Enthält den Namen des ausgewählten Protokollierungsnamensraums, wenn die Einstellung \fILogNamespace=\fP verwandt wird\&. .RE .PP \fI$JOURNAL_STREAM\fP .RS 4 Falls die Standardausgabe oder Standardfehlerausgabe des ausgeführten Prozesses mit dem Journal verbunden ist (beispielsweise durch Setzen von \fIStandardError=journal\fP), enthält \fI$JOURNAL_STREAM\fP das Gerät und die Inode\-Nummer des verbindenden Dateideskriptors, dezimal formatiert, getrennt durch einen Doppelpunkt (»:«)\&. Dies erlaubt es aufgerufenen Prozessen, sicher zu überprüfen, ob ihre Standardausgabe oder Standardfehlerausgabe mit dem Journal verbunden sind\&. Das Gerät und die Inode\-Nummer des Dateideskriptors sollte mit den in der Umgebungsvariable gesetzten Werten verglichen werden, um zu bestimmen, ob die Prozessausgabe immer noch mit dem Journal verbunden ist\&. Beachten Sie, dass es im Allgemeinen nicht ausreicht, zu prüfen, ob \fI$JOURNAL_STREAM\fP überhaupt gesetzt ist, da Dienste externe Prozesse aufrufen könnten, die ihre Standardausgabe oder Fehlerausgabe ersetzen könnten, ohne dabei die Umgebungsvariable zurückzusetzen\&. .sp Falls sowohl die Standardausgabe als auch der Standardfehler des ausgeführten Prozesses mit dem Journal über ein Datenstrom\-Socket verbunden sind, wird diese Umgebungsvariable Informationen über den Standardfehlerdatenstrom enthalten, da dies normalerweise das bevorzugte Ziel für Protokolldaten ist\&. (Beachten Sie, dass typischerweise der gleiche Datenstrom sowohl für die Standardausgabe als auch den Standardfehler verwandt wird und daher die Umgebungsvariable sehr wahrscheinlich Geräte\- und Inode\-Informationen enthalten wird, die auf beide Datenstromdateideskriptoren passt\&.) .sp Diese Umgebungsvariable ist hauptsächlich nützlich, um Diensten zu erlauben, ihr verwandtes Protokollierungsprotokoll optional (mittels \fBsd_journal_print\fP(3) und anderer Funktionen) auf das native Journal\-Protokoll anzuheben, falls ihre Standardausgabe oder Standardfehlerausgabe sowieso mit dem Journal verbunden ist\&. Damit wird die Lieferung von strukturierten Metadaten zusammen mit den protokollierten Nachrichten ermöglicht\&. .RE .PP \fI$SERVICE_RESULT\fP .RS 4 Diese Variable, die nur für den Dienste\-Unit\-Typ definiert ist, wird an alle \fIExecStop=\fP\- und \fIExecStopPost=\fP\-Prozesse weitergegeben und kodiert das »Ergebnis« des Prozesses\&. Derzeit sind die folgenden Werte definiert: .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&5.\ \&Definierte \fP\fI$SERVICE_RESULT\fP\-Werte .TS allbox tab(:); lB lB. T{ Wert T}:T{ Bedeutung T} .T& l l l l l l l l l l l l l l l l l l. T{ "Erfolg" T}:T{ Der Dienst lief erfolgreich und beendete sich ordnungsgemäß\&. T} T{ "protocol" T}:T{ Das Protokoll wurde verletzt: der Dienst hat nicht die von seiner Unit\-Konfiguration verlangten Schritte absolviert (insbesondere was in der Einstellung \fIType=\fP konfiguriert wurde)\&. T} T{ "timeout" T}:T{ Einer der Schritte hat die Zeit überschritten\&. T} T{ "exit\-code" T}:T{ Diensteprozess hat sich mit einen von Null verschiedenen Exit\-Code beendet; siehe \fI$EXIT_CODE\fP unten für den tatsächlich zurückgelieferten Exit\-Code\&. T} T{ "signal" T}:T{ Ein Diensteprozess wurde durch ein Signal regelwidrig beendet; ohne einen Speicherauszug\&. Siehe \fI$EXIT_CODE\fP unten für das tatsächliche Signal, das die Beendigung auslöste\&. T} T{ "core\-dump" T}:T{ Ein Diensteprozess wurde durch ein Signal regelwidrig beendet und hat einen Speicherauszug ausgegeben\&. Siehe \fI$EXIT_CODE\fP unten für das Signal, das die Beendigung auslöste\&. T} T{ "watchdog" T}:T{ Der Totmannschalter des Watchdogs war für diesen Dienst aktiviert, aber die Frist wurde verpasst\&. T} T{ "start\-limit\-hit" T}:T{ Für die Unit war eine Startbegrenzung definiert und wurde erreicht, wodurch der Start der Unit fehlschlug\&. Siehe \fIStartLimitIntervalSec=\fP und \fIStartLimitBurst=\fP von \fBsystemd.unit\fP(5) für Details\&. T} T{ "resources" T}:T{ Eine Auffangbedingung, falls eine Systemaktion fehlschlug\&. T} .TE .sp 1 Diese Umgebungsvariable ist nützlich, um den Fehlschlag oder die erfolgreiche Beendigung eines Dienstes zu überwachen\&. Obwohl diese Variable sowohl in \fIExecStop=\fP als auch \fIExecStopPost=\fP verfügbar ist, ist es normalerweise eine bessere Wahl, die Überwachungswerkzeuge in Letzterer zu platzieren, da Erstere nur für Dienste aufgerufen wird, die ihren Start korrekt verwaltet haben und Letztere sowohl Dienste abdeckt, die während ihres Startens fehlschlugen als auch solche, die während ihrer Laufzeit fehlschlugen\&. .RE .PP \fI$EXIT_CODE\fP, \fI$EXIT_STATUS\fP .RS 4 Diese Umgebungsvariablen, die nur für den Dienste\-Unit\-Typ definiert sind, werden an alle Prozesse aus \fIExecStop=\fP und \fIExecStopPost=\fP übergeben und enthalten Exit\-Status/Code\-Informationen über den Hauptprozess des Dienstes\&. Für die genaue Definition des Exit\-Codes und \-Status, siehe \fBwait\fP(2)\&. \fI$EXIT_CODE\fP ist entweder »exited«, »killed« oder »dumped«\&. \fI$EXIT_STATUS\fP enthält den als Zeichenkette formatierten numerischen Exit\-Code, falls \fI$EXIT_CODE\fP »exited« enthält und andernfalls den Signalnamen\&. Beachten Sie, dass diese Umgebungsvariablen nur gesetzt sind, falls es dem Diensteverwalter gelang, den Hauptprozess des Dienstes zu starten und zu identifizieren\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&6.\ \&Zusammenfassung der möglichen Variablenwerte für Diensteergebnisse\fP .TS allbox tab(:); lB lB lB. T{ \fI$SERVICE_RESULT\fP T}:T{ \fI$EXIT_CODE\fP T}:T{ \fI$EXIT_STATUS\fP T} .T& lt lt l ^ lt l lt lt l ^ l l lt lt l ^ lt l lt lt l lt lt l lt lt l lt l l ^ l l ^ l l lt l l lt lt l l l l l l l l s s. T{ "Erfolg" T}:T{ "killed" T}:T{ »HUP«, »INT«, »TERM«, »PIPE« T} :T{ "exited" T}:T{ "0" T} T{ "protocol" T}:T{ not set T}:T{ not set T} :T{ "exited" T}:T{ "0" T} T{ "timeout" T}:T{ "killed" T}:T{ »TERM«, »KILL« T} :T{ "exited" T}:T{ »0«, »1«, »2«, »3«, … »255« T} T{ "exit\-code" T}:T{ "exited" T}:T{ »1«, »2«, »3«, …, »255« T} T{ "signal" T}:T{ "killed" T}:T{ »HUP«, »INT«, »KILL«, … T} T{ "core\-dump" T}:T{ "dumped" T}:T{ »ABRT«, »SEGV«, »QUIT«, … T} T{ "watchdog" T}:T{ "dumped" T}:T{ "ABRT" T} :T{ "killed" T}:T{ »TERM«, »KILL« T} :T{ "exited" T}:T{ »0«, »1«, »2«, »3«, … »255« T} T{ "exec\-condition" T}:T{ "exited" T}:T{ »1«, »2«, »3«, »4«, …, »254« T} T{ "oom\-kill" T}:T{ "killed" T}:T{ »TERM«, »KILL« T} T{ "start\-limit\-hit" T}:T{ not set T}:T{ not set T} T{ "resources" T}:T{ jeder der obigen T}:T{ jeder der obigen T} T{ Beachten Sie: der Prozess kann auch durch ein Signal beendet werden, das nicht von Systemd gesandt wurde\&. Insbesondere kann der Prozess sich selbst in einem Handler ein beliebiges Signal für jedes der nicht maskierbaren Signale senden\&. Nichtsdestotrotz wurden in den Spalten »timeout« und »watchdog« nur die Signale aufgenommen, die Systemd sendet\&. Desweiteren können mittels \fISuccessExitStatus=\fP zusätzliche Exit\-Status erklärt werden, um die ordnungsgemäße Beendigung anzuzeigen, was in der Tabelle nicht wiedergegeben wird\&. T} .TE .sp 1 .RE .PP \fI$PIDFILE\fP .RS 4 Der Pfad zu der konfigurierten PID\-Datei, falls der Prozess im Auftrag des Dienstes, der die Einstellung \fIPIDFile=\fP verwendet, einen Fork durchgeführt hat, siehe \fBsystemd.service\fP(5) für Details\&. Dienste\-Code kann diese Umgebungsvariable verwenden, um automatisch eine PID\-Datei am durch die Unit\-Datei konfigurierten Ort zu erstellen\&. Dieses Feld ist auf einen absoluten Pfad in dem Dateisystem gesetzt\&. .RE .PP Für Systemdienste können zusätzliche, durch Systemd definierte Umgebungsvariablen für Dienste gesetzt werden, wenn \fIPAMName=\fP aktiviert und \fBpam_systemd\fP Teil des ausgewählten PAM\-Stacks ist\&. Dies sind insbesondere \fI$XDG_SEAT\fP und \fI$XDG_VTNR\fP, siehe \fBpam_systemd\fP(8) für Details\&. .SH PROZESS\-EXIT\-CODES .PP Beim Aufruf eines Unit\-Prozesses könnte der Diensteverwalter möglicherweise nicht in der Lage sein, die mit den oben dargestellten Einstellungen konfigurierten Ausführungsparameter zu setzen\&. In diesem Fall wird sich der bereits erstellte Diensteprozess mit einem von Null verschiedenen Exit\-Code beenden, bevor die konfigurierte Befehlszeile ausgeführt wird\&. (Oder, mit anderen Worten, der Kindprozess hat sich mit diesen Fehler\-Codes beendet, nachdem er mit dem Systemaufruf \fBfork\fP(2) erstellt wurde, aber bevor der zugehörige Systemaufruf \fBexecve\fP(2) erfolgte\&.) Insbesondere werden die durch die C\-Bibliothek, die LSB\-Spezifikation und durch den Systemd\-Diensteverwalter selbst definierten Exit\-Codes verwandt\&. .PP Die folgenden grundlegenden Dienste\-Exit\-Codes sind durch die C\-Bibliothek definiert\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&7.\ \&Grundlegende Exit\-Codes der C\-Bibliothek\fP .TS allbox tab(:); lB lB lB. T{ Exit\-Code T}:T{ Symbolischer Name T}:T{ Beschreibung T} .T& l l l l l l. T{ 0 T}:T{ \fBEXIT_SUCCESS\fP T}:T{ Generischer Erfolgs\-Code\&. T} T{ 1 T}:T{ \fBEXIT_FAILURE\fP T}:T{ Generischer Fehlschlag oder unspezifizierter Fehler\&. T} .TE .sp 1 .PP Die folgenden Dienste\-Exit\-Codes sind durch die \m[blue]\fBLSB\-Spezifikation\fP\m[]\&\s-2\u[10]\d\s+2 festgelegt\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&8.\ \&LSB\-Dienste\-Exit\-Codes\fP .TS allbox tab(:); lB lB lB. T{ Exit\-Code T}:T{ Symbolischer Name T}:T{ Beschreibung T} .T& l l l l l l l l l l l l l l l l l l. T{ 2 T}:T{ \fBEXIT_INVALIDARGUMENT\fP T}:T{ Ungültige oder überzählige Argumente\&. T} T{ 3 T}:T{ \fBEXIT_NOTIMPLEMENTED\fP T}:T{ Nicht implementierte Funktionalität\&. T} T{ 4 T}:T{ \fBEXIT_NOPERMISSION\fP T}:T{ Der Benutzer hat nicht genug Privilegien\&. T} T{ 5 T}:T{ \fBEXIT_NOTINSTALLED\fP T}:T{ Das Programm ist nicht installiert\&. T} T{ 6 T}:T{ \fBEXIT_NOTCONFIGURED\fP T}:T{ Das Programm ist nicht konfiguriert\&. T} T{ 7 T}:T{ \fBEXIT_NOTRUNNING\fP T}:T{ Das Programm läuft nicht\&. T} .TE .sp 1 .PP Die LSB\-Spezifikation schlägt vor, dass Fehler\-Code 200 und höher für Implementierungen reserviert ist\&. Einige von ihnen werden vom Diensteverwalter benutzt, um Probleme beim Aufrufen von Prozessen anzuzeigen\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&9.\ \&Systemd\-spezifische Exit\-Codes\fP .TS allbox tab(:); lB lB lB. T{ Exit\-Code T}:T{ Symbolischer Name T}:T{ Beschreibung T} .T& l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l. T{ 200 T}:T{ \fBEXIT_CHDIR\fP T}:T{ Änderung des angeforderten Arbeitsverzeichnisses schlug fehl\&. Siehe \fIWorkingDirectory=\fP oben\&. T} T{ 201 T}:T{ \fBEXIT_NICE\fP T}:T{ Scheduling\-Priorität (Nice\-Stufe) konnte nicht gesetzt werden\&. Siehe \fINice=\fP oben\&. T} T{ 202 T}:T{ \fBEXIT_FDS\fP T}:T{ Ungewünschter Dateideskriptor konnte nicht geschlossen werden oder übergebene Dateideskriptoren konnten nicht angepasst werden\&. T} T{ 203 T}:T{ \fBEXIT_EXEC\fP T}:T{ Die tatsächliche Ausführung des Prozesses schlug fehl (genauer, der Systemaufruf \fBexecve\fP(2))\&. Höchstwahrscheinlich wird dies durch ein fehlendes oder nicht zugreifbares Programm hervorgerufen\&. T} T{ 204 T}:T{ \fBEXIT_MEMORY\fP T}:T{ Aufgrund von Speicherknappheit konnte eine Aktion nicht durchgeführt werden\&. T} T{ 205 T}:T{ \fBEXIT_LIMITS\fP T}:T{ Ressourcenbegrenzungen konnten nicht angepasst werden\&. Siehe \fILimitCPU=\fP und verwandte Einstellungen oben\&. T} T{ 206 T}:T{ \fBEXIT_OOM_ADJUST\fP T}:T{ OOM\-Einstellungen konnten nicht angepasst werden\&. Siehe \fIOOMScoreAdjust=\fP oben\&. T} T{ 207 T}:T{ \fBEXIT_SIGNAL_MASK\fP T}:T{ Prozesssignalmaske konnte nicht gesetzt werden\&. T} T{ 208 T}:T{ \fBEXIT_STDIN\fP T}:T{ Standardeingabe konnte nicht gesetzt werden\&. Siehe \fIStandardInput=\fP oben\&. T} T{ 209 T}:T{ \fBEXIT_STDOUT\fP T}:T{ Standardausgabe konnte nicht gesetzt werden\&. Siehe \fIStandardOutput=\fP oben\&. T} T{ 210 T}:T{ \fBEXIT_CHROOT\fP T}:T{ Wurzelverzeichnis konnte nicht geändert werden (\fBchroot\fP(2))\&. Siehe \fIRootDirectory=\fP/\fIRootImage=\fP oben\&. T} T{ 211 T}:T{ \fBEXIT_IOPRIO\fP T}:T{ E/A\-Scheduling\-Priorität konnte nicht gesetzt werden\&. Siehe \fIIOSchedulingClass=\fP/\fIIOSchedulingPriority=\fP oben\&. T} T{ 212 T}:T{ \fBEXIT_TIMERSLACK\fP T}:T{ Der Timer\-Spielraum konnte nicht eingerichtet werden. Siehe \fITimerSlackNSec=\fP oben\&. T} T{ 213 T}:T{ \fBEXIT_SECUREBITS\fP T}:T{ Prozess\-Sicherheits\-Bits konnten nicht gesetzt werden\&. Siehe \fISecureBits=\fP oben\&. T} T{ 214 T}:T{ \fBEXIT_SETSCHEDULER\fP T}:T{ CPU\-Scheduling konnte nicht eingerichtet werden\&. Siehe \fICPUSchedulingPolicy=\fP/\fICPUSchedulingPriority=\fP oben\&. T} T{ 215 T}:T{ \fBEXIT_CPUAFFINITY\fP T}:T{ CPU\-Affinität konnte nicht eingerichtet werden\&. Siehe \fICPUAffinity=\fP oben\&. T} T{ 216 T}:T{ \fBEXIT_GROUP\fP T}:T{ Gruppen\-Zugangsdaten konnten nicht bestimmt oder geändert werden\&. Siehe \fIGroup=\fP/\fISupplementaryGroups=\fP oben\&. T} T{ 217 T}:T{ \fBEXIT_USER\fP T}:T{ Benutzer\-Zugangsdaten konnten nicht bestimmt oder geändert werden oder Benutzernamensräume eingerichtet werden\&. Siehe \fIUser=\fP/\fIPrivateUsers=\fP oben\&. T} T{ 218 T}:T{ \fBEXIT_CAPABILITIES\fP T}:T{ Capabilities konnten nicht abgegeben oder Umgebungs\-Capabilities angewandt werden\&. Siehe \fICapabilityBoundingSet=\fP/\fIAmbientCapabilities=\fP oben\&. T} T{ 219 T}:T{ \fBEXIT_CGROUP\fP T}:T{ Einrichten der Dienste\-Control\-Gruppe schlug fehl\&. T} T{ 220 T}:T{ \fBEXIT_SETSID\fP T}:T{ Erstellung einer neuen Prozesssitzung schlug fehl\&. T} T{ 221 T}:T{ \fBEXIT_CONFIRM\fP T}:T{ Ausführung wurde vom Benutzer abgebrochen\&. Siehe die Kernelbefehlszeileneinstellung \fIsystemd\&.confirm_spawn=\fP in \fBkernel\-command\-line\fP(7) für Details\&. T} T{ 222 T}:T{ \fBEXIT_STDERR\fP T}:T{ Standardfehlerausgabe konnte nicht eingerichtet werden\&. Siehe \fIStandardError=\fP oben\&. T} T{ 224 T}:T{ \fBEXIT_PAM\fP T}:T{ PAM\-Sitzung konnte nicht eingerichtet werden\&. Siehe \fIPAMName=\fP oben\&. T} T{ 225 T}:T{ \fBEXIT_NETWORK\fP T}:T{ Netzwerknamensräume konnten nicht eingericht werden\&. Siehe \fIPrivateNetwork=\fP oben\&. T} T{ 226 T}:T{ \fBEXIT_NAMESPACE\fP T}:T{ Einhängenamensräume konnten nicht eingerichtet werden\&. Siehe \fIReadOnlyPaths=\fP und verwandte Einstellungen oben\&. T} T{ 227 T}:T{ \fBEXIT_NO_NEW_PRIVILEGES\fP T}:T{ Neue Privilegien konnten nicht deaktiviert werden\&. Siehe \fINoNewPrivileges=yes\fP oben\&. T} T{ 228 T}:T{ \fBEXIT_SECCOMP\fP T}:T{ Systemaufruffilter konnten nicht angewandt werden\&. Siehe \fISystemCallFilter=\fP und verwandte Einstellungen oben\&. T} T{ 229 T}:T{ \fBEXIT_SELINUX_CONTEXT\fP T}:T{ SELinux\-Kontext konnte nicht bestimmt oder geändert werden\& Siehe \fISELinuxContext=\fP oben\&. T} T{ 230 T}:T{ \fBEXIT_PERSONALITY\fP T}:T{ Ausführungsdomäne (Personalität) konnte nicht eingerichtet werden\&. Siehe \fIPersonality=\fP oben\&. T} T{ 231 T}:T{ \fBEXIT_APPARMOR_PROFILE\fP T}:T{ AppArmor konnte nicht vorbereitet werden\&. SIehe \fIAppArmorProfile=\fP oben\&. T} T{ 232 T}:T{ \fBEXIT_ADDRESS_FAMILIES\fP T}:T{ Adressfamilien konnten nicht beschränkt werden\&. Siehe \fIRestrictAddressFamilies=\fP oben\&. T} T{ 233 T}:T{ \fBEXIT_RUNTIME_DIRECTORY\fP T}:T{ Laufzeitverzeichnis konnte nicht eingerichtet werden\&. Siehe \fIRuntimeDirectory=\fP und verwandte Einstellungen oben\&. T} T{ 235 T}:T{ \fBEXIT_CHOWN\fP T}:T{ Socket\-Eigentümerschaft konnte nicht angepasst werden\&. Wird nur für Socket\-Units verwandt\&. T} T{ 236 T}:T{ \fBEXIT_SMACK_PROCESS_LABEL\fP T}:T{ SMACK\-Sicherheits\-Label konnte nicht gesetzt werden\&. Siehe \fISmackProcessLabel=\fP oben\&. T} T{ 237 T}:T{ \fBEXIT_KEYRING\fP T}:T{ Kernel\-Schlüsselbund konnte nicht eingerichtet werden\&. T} T{ 238 T}:T{ \fBEXIT_STATE_DIRECTORY\fP T}:T{ Zustandsverzeichnis der Unit konnte nicht eingerichtet werden\&. Siehe \fIStateDirectory=\fP oben\&. T} T{ 239 T}:T{ \fBEXIT_CACHE_DIRECTORY\fP T}:T{ Zwischenspeicherverzeichnis der Unit konnte nicht eingerichtet werden\&. Siehe \fICacheDirectory=\fP oben\&. T} T{ 240 T}:T{ \fBEXIT_LOGS_DIRECTORY\fP T}:T{ Protokollierverzeichnis der Unit konnte nicht eingerichtet werden\&. Siehe \fILogsDirectory=\fP oben\&. T} T{ 241 T}:T{ \fBEXIT_CONFIGURATION_DIRECTORY\fP T}:T{ Konfigurationsverzeichnis der Unit konnte nicht eingerichtet werden\&. Siehe \fIConfigurationDirectory=\fP oben\&. T} T{ 242 T}:T{ \fBEXIT_NUMA_POLICY\fP T}:T{ NUMA\-Richtlinie der Unit konnte nicht eingerichtet werden\&. Siehe \fINUMAPolicy=\fP und \fINUMAMask=\fP oben\&. T} T{ 243 T}:T{ \fBEXIT_CREDENTIALS\fP T}:T{ Zugangsdaten der Unit konnten nicht eingerichtet werden\&. Siehe \fILoadCredential=\fP und \fISetCredential=\fP oben\&. T} .TE .sp 1 .PP Schließlich definieren die BSD\-Betriebssysteme eine Reihe von Exit\-Codes, die typischerweise auch auf Linux\-Systemen definiert sind: .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br \fBTabelle\ \&10.\ \&BSD\-Exit\-Codes\fP .TS allbox tab(:); lB lB lB. T{ Exit\-Code T}:T{ Symbolischer Name T}:T{ Beschreibung T} .T& l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l l. T{ 64 T}:T{ \fBEX_USAGE\fP T}:T{ Befehlszeilenbenutzungsfehler T} T{ 65 T}:T{ \fBEX_DATAERR\fP T}:T{ Datenformatfehler T} T{ 66 T}:T{ \fBEX_NOINPUT\fP T}:T{ Eingabe kann nicht geöffnet werden T} T{ 67 T}:T{ \fBEX_NOUSER\fP T}:T{ Empfängerin unbekannt T} T{ 68 T}:T{ \fBEX_NOHOST\fP T}:T{ Rechnername unbekannt T} T{ 69 T}:T{ \fBEX_UNAVAILABLE\fP T}:T{ Dienst nicht verfügbar T} T{ 70 T}:T{ \fBEX_SOFTWARE\fP T}:T{ interner Softwarefehler T} T{ 71 T}:T{ \fBEX_OSERR\fP T}:T{ Systemfehler (z\&.B\&. Fork kann nicht ausgeführt werden) T} T{ 72 T}:T{ \fBEX_OSFILE\fP T}:T{ kritische Betriebssystemdatei fehlt T} T{ 73 T}:T{ \fBEX_CANTCREAT\fP T}:T{ (Benutzer)\-Ausgabedatei kann nicht erstellt werden T} T{ 74 T}:T{ \fBEX_IOERR\fP T}:T{ Eingabe/Ausgabe\-Fehler T} T{ 75 T}:T{ \fBEX_TEMPFAIL\fP T}:T{ Temporärer Fehlschlag, Benutzer sollte es noch einmal versuchen T} T{ 76 T}:T{ \fBEX_PROTOCOL\fP T}:T{ Ferner Fehler im Protokoll T} T{ 77 T}:T{ \fBEX_NOPERM\fP T}:T{ Erlaubnis verweigert T} T{ 78 T}:T{ \fBEX_CONFIG\fP T}:T{ Konfigurationsfehler T} .TE .sp 1 .SH "SIEHE AUCH" .PP \fBsystemd\fP(1), \fBsystemctl\fP(1), \fBsystemd\-analyze\fP(1), \fBjournalctl\fP(1), \fBsystemd\-system.conf\fP(5), \fBsystemd.unit\fP(5), \fBsystemd.service\fP(5), \fBsystemd.socket\fP(5), \fBsystemd.swap\fP(5), \fBsystemd.mount\fP(5), \fBsystemd.kill\fP(5), \fBsystemd.resource\-control\fP(5), \fBsystemd.time\fP(7), \fBsystemd.directives\fP(7), \fBtmpfiles.d\fP(5), \fBexec\fP(3), \fBfork\fP(2) .SH ANMERKUNGEN .IP " 1." 4 Spezifikation für auffindbare Partitionen .RS 4 \%https://systemd.io/DISCOVERABLE_PARTITIONS .RE .IP " 2." 4 Das /proc\-Dateisystem .RS 4 \%https://www.kernel.org/doc/html/latest/filesystems/proc.html#mount\-options .RE .IP " 3." 4 Benutzer\-/Gruppennamen\-Syntax .RS 4 \%https://systemd.io/USER_NAMES .RE .IP " 4." 4 Schalter »Keine neuen Privilegien« .RS 4 \%https://www.kernel.org/doc/html/latest/userspace\-api/no_new_privs.html .RE .IP " 5." 4 JSON\-Benutzerdatensatz .RS 4 \%https://systemd.io/USER_RECORD .RE .IP " 6." 4 proc.txt .RS 4 \%https://www.kernel.org/doc/Documentation/filesystems/proc.txt .RE .IP " 7." 4 C\-Maskierungen .RS 4 \%https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences .RE .IP " 8." 4 die meisten Steuerzeichen .RS 4 \%https://en.wikipedia.org/wiki/Control_character#In_ASCII .RE .IP " 9." 4 Base64 .RS 4 \%https://tools.ietf.org/html/rfc2045#section\-6.8 .RE .IP 10. 4 LSB\-Spezifikation .RS 4 \%https://refspecs.linuxbase.org/LSB_5.0.0/LSB\-Core\-generic/LSB\-Core\-generic/iniscrptact.html .RE .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die .MT debian-l10n-german@\:lists.\:debian.\:org Mailingliste der Übersetzer .ME .