Provided by: manpages-de_4.15.0-9_all 
BEZEICHNUNG
systemd-analyze - Systemverwalter analysieren und auf Fehler überprüfen
ÜBERSICHT
systemd-analyze [OPTIONEN…] [Zeit]
systemd-analyze [OPTIONEN…] blame
systemd-analyze [OPTIONEN…] critical-chain [UNIT…]
systemd-analyze [OPTIONEN…] dump
systemd-analyze [OPTIONEN…] plot [>Datei.svg]
systemd-analyze [OPTIONEN…] dot [MUSTER…] [>Datei.dot]
systemd-analyze [OPTIONEN…] unit-paths
systemd-analyze [OPTIONEN…] exit-status [STATUS…]
systemd-analyze [OPTIONEN…] capability [CAPABILITY…]
systemd-analyze [OPTIONEN…] condition BEDINGUNG…
systemd-analyze [OPTIONEN…] syscall-filter [GRUPPE…]
systemd-analyze [OPTIONEN…] filesystems [GRUPPE…]
systemd-analyze [OPTIONEN…] calendar SPEZ…
systemd-analyze [OPTIONEN…] timestamp ZEITSTEMPEL…
systemd-analyze [OPTIONEN…] timespan SPANNE…
systemd-analyze [OPTIONEN…] cat-config NAME|PFAD…
systemd-analyze [OPTIONEN…] verify [DATEI…]
systemd-analyze [OPTIONEN…] security UNIT…
BESCHREIBUNG
systemd-analyze kann zur Bestimmung der Systemstartleistungsstatistik benutzt werden. Es
kann Status- und Nachverfolgungsinformationen aus dem System- und Diensteverwalter abrufen
und die Korrektheit von Unit-Dateien überprüfen. Es wird auch dazu verwandt, auf besondere
Funktionen zuzugreifen, die für fortgeschrittene Systemverwalterfehlersuche nützlich sind.
Falls kein Befehl übergeben wird, wird systemd-analyze time impliziert.
systemd-analyze time
Dieser Befehl gibt die im Kernel verbrachte Zeit, bevor der Anwendungsbereich erreicht
wurde, die Zeit, die in der anfänglichen RAM-Platte (Initrd), bevor die normale
Systemanwendungsebene erreicht wurde und die Zeit, die die normale Systemanwendungsebene
zur Initialisierung benötigte, aus. Beachten Sie, dass diese Messungen einfach die Zeit zu
dem Punkt messen, an dem alle Systemdienste gestartet wurden, aber nicht notwendigerweise
bis sie ihre Initialisierung abgeschlossen hatten oder die Platte im Leerlauf war.
Beispiel 1. Anzeigen, wie lange ein Systemstart brauchte
# in einem Container
$ systemd-analyze time
Startup finished in 296ms (userspace)
multi-user.target reached after 275ms in userspace
# in einer echten Maschine
$ systemd-analyze time
Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
multi-user.target reached after 47.820s in userspace
systemd-analyze blame
Dieser Befehl gibt eine Liste aller laufenden Units, sortiert nach der
Initialisierungszeitdauer, aus. Diese Informationen können zur Optimierung der
Systemstartzeit verwandt werden. Beachten Sie, dass die Ausgabe irreführend sein kann, da
die Initialisierung eines Dienstes einfach deshalb langsam sein kann, da sie auf den
Abschluss der Initialisierung eines anderen Dienstes wartet. Beachten Sie auch:
systemd-analyze blame zeigt keine Ergebnisse für Dienste mit Type=simple an, da Systemd
solche Dienste als sofort gestartet betrachtet und daher keine Messungen der
Initialisierungsverzögerungen erfolgen können. Beachten Sie auch, dass dieser Befehl nur
die Zeit anzeigt, die die Units für das Hochfahren benötigten, er zeigt nicht an, wie
lange sich die Units in der Ausführungswarteschlange befanden. Insbesondere zeigt er die
Zeit, die die Units im Zustand »activating« verbrachten; dieser Zustand ist für Units wie
Geräte-Units nicht definiert, die direkt von »inactive« nach »active« übergehen. Dieser
Befehl gibt daher den Eindruck der Leistung von Programmcode, kann aber nicht die durch
das Warten auf Hardware und ähnliche Ereignisse verursachte Latenz genau wiedergeben.
Beispiel 2. Zeigt, welche Units beim Systemstart die meiste Zeit verbrauchten
$ systemd-analyze blame
32.875s pmlogger.service
20.905s systemd-networkd-wait-online.service
13.299s dev-vda1.device
...
23ms sysroot.mount
11ms initrd-udevadm-cleanup-db.service
3ms sys-kernel-config.mount
systemd-analyze critical-chain [UNIT…]
Dieser Befehl gibt einen Baum der zeitkritischen Unit-Kette (für jede der angegebenen
UNITs oder andernfalls für das Standardziel) aus. Die Zeit, nach der die Unit aktiv oder
gestartet ist, wird nach dem Zeichen »@« ausgegeben. Die Zeit, die die Unit zum Starten
benötigt, wird nach dem Zeichen »+« ausgegeben. Beachten Sie, dass die Ausgabe irreführend
sein kann, da die Initialisierung von Diensten abhängig von der Aktivierung eines Sockets
sein kann und da die Units parallel ausgeführt werden. Dies berücksichtigt auch ähnlich zu
dem Befehl blame nur die Zeit, die die Unit im Zustand »activating« verbringt und deckt
daher Units nicht ab, die niemals durch den Zustand »inactive« laufen (wie beispielsweise
Geräte-Units, die direkt von »inactive« zu »active« übergehen). Desweiteren zeigt es keine
Informationen über Aufträge an (und insbesondere über Aufträge, die eine
Zeitüberschreitung erlebten).
Beispiel 3. systemd-analyze critical-chain
$ systemd-analyze critical-chain
multi-user.target @47.820s
└─pmie.service @35.968s +548ms
└─pmcd.service @33.715s +2.247s
└─network-online.target @33.712s
└─systemd-networkd-wait-online.service @12.804s +20.905s
└─systemd-networkd.service @11.109s +1.690s
└─systemd-udevd.service @9.201s +1.904s
└─systemd-tmpfiles-setup-dev.service @7.306s +1.776s
└─kmod-static-nodes.service @6.976s +177ms
└─systemd-journald.socket
└─system.slice
└─-.slice
systemd-analyze dump
Dieser Befehl gibt eine (normalerweise sehr lange) menschenlesbare Serialisierung des
kompletten Serverzustandes aus. Sein Format unterliegt ohne Ankündigungen Änderungen und
sollte nicht durch Anwendungen ausgewertet werden.
Beispiel 4. Den internen Zustand des Benutzerverwalters anzeigen
$ systemd-analyze --user dump
Timestamp userspace: Thu 2019-03-14 23:28:07 CET
Timestamp finish: Thu 2019-03-14 23:28:07 CET
Timestamp generators-start: Thu 2019-03-14 23:28:07 CET
Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET
-> Unit proc-timer_list.mount:
Description: /proc/timer_list
...
-> Unit default.target:
Description: Main user target
…
systemd-analyze plot
Dieser Befehl gibt eine SVG-Graphik aus, die detailliert, welche Systemdienste zu welcher
Zeit gestartet wurden und hervorhebt, welche Zeit sie zur Initialisierung verbraucht
haben.
Beispiel 5. Eine Systemstartübersicht darstellen
$ systemd-analyze plot >bootup.svg
$ eog bootup.svg&
systemd-analyze dot [Muster…]
Dieser Befehl erstellt eine textuelle Abhängigkeitsgraphbeschreibung im Dot-Format zur
weiteren Verarbeitung mit dem GraphViz-Werkzeug dot(1). Verwenden Sie eine Befehlszeile
der Art systemd-analyze dot | dot -Tsvg >systemd.svg, um einen graphischen
Abhängigkeitsbaum zu erstellen. Falls weder --order noch --require angegeben sind, wird
der erstellte Graph sowohl Ordnungs- als auch Anforderungsabhängigkeiten darstellen.
Optional können am Ende Muster-Festlegungen im Glob-Stil (z.B. *.target) angegeben werden.
Eine Unit-Abhängigkeit ist im Graph enthalten, falls eines dieser Muster entweder auf den
Quell- oder den Zielknoten passt.
Beispiel 6. Zeichnet alle Abhängigkeiten von jeder Unit, deren Name mit »avahi-daemon«
beginnt
$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg
$ eog avahi.svg
Beispiel 7. Zeichnet alle Abhängigkeiten zwischen allen bekannten Ziel-Units
$ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \
| dot -Tsvg >Ziele.svg
$ eog Ziele.svg
systemd-analyze unit-paths
Dieser Befehl gibt eine Liste aller Verzeichnisse aus, aus denen Unit-Dateien, .d
overrides- und .wants-, .requires-Symlinks geladen werden können. Kombinieren Sie dies mit
--user, um die Liste für die Benutzerverwalterinstanz abzufragen und --global für die
globale Konfiguration der Benutzerverwalterinstanzen.
Beispiel 8. Alle Pfade für erstellte Units anzeigen
$ systemd-analyze unit-paths | grep '^/run'
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/run/systemd/system
/run/systemd/system.attached
/run/systemd/generator
/run/systemd/generator.late
Beachten Sie, dass dieser Unterbefehl die Liste ausgibt, die in systemd-analyze selbst
einkompiliert wurde und keine Kommunikation mit dem laufenden Verwalter stattfindet.
Verwenden Sie
systemctl [--user] [--global] show -p Unit-Pfad --value
um die tatsächliche Liste, die der Verwalter benutzt, abzufragen, wobei alle leeren
Verzeichnisse ausgelassen werden.
systemd-analyze exit-status [STATUS…]
Dieser Befehl gibt eine Liste von Exit-Status zusammen mit ihrer »Klasse« aus, d.h. der
Quelle der Definition (entweder »glibc«, »systemd«, »LSB« oder »BSD«), siehe den Abschnitt
PROZESS-EXIT-CODES in systemd.exec(5). Falls keine zusätzlichen Argumente angegeben sind,
werden alle bekannten Status angezeigt. Andernfalls werden nur die Definitionen für die
angegebenen Codes angezeigt.
Beispiel 4. Ein paar Beispiel-Exit-Status anzeigen
$ systemd-analyze exit-status 0 1 {63..65}
NAME STATUS CLASS
SUCCESS 0 glibc
FAILURE 1 glibc
- 63 -
USAGE 64 BSD
DATAERR 65 BSD
systemd-analyze capability [CAPABILITY…]
Dieser Befehl gibt eine Liste der Linux-Capabilities zusammen mit ihren numerischen
Kennungen aus. Siehe capabilities(7) für Details. Falls kein Argument angegeben ist, wird
die vollständige Liste der dem Diensteverwalter und dem Kernel bekannten Capabilities
ausgegeben. Capabilities, die vom Kernel definiert werden aber dem Diensteverwalter nicht
bekannt sind, werden als »cap_???« angezeigt. Falls Argumente angegeben sind, können sich
diese optional auch auf bestimmte Capabilities über ihren Namen oder ihre numerische
Kennung beziehen, wodurch dann nur die bezeichneten Capabilities in der Tabelle angezeigt
werden.
Beispiel 10. Ein paar Beispiel-Capability-Namen anzeigen
$ systemd-analyze capability 0 1 {30..32}
NAME NUMBER
cap_chown 0
cap_dac_override 1
cap_audit_control 30
cap_setfcap 31
cap_mac_override 32
systemd-analyze condition BEDINGUNG…
Dieser Befehl wertet die Zuweisungen Condition*=… und Assert*=… aus und gibt ihre Werte
und den daraus ergebenen Wert des kombinierten Bedingungssatzes aus. Siehe systemd.unit(5)
für eine Liste der verfügbaren Bedingungen und Zusicherungen.
Beispiel 11. Bedingungen auswerten, die Kernelversionen prüfen
$ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
'ConditionKernelVersion = >=5.1' \
'ConditionACPower=|false' \
'ConditionArchitecture=|!arm' \
'AssertPathExists=/etc/os-release'
test.service: AssertPathExists=/etc/os-release succeeded.
Asserts succeeded.
test.service: ConditionArchitecture=|!arm succeeded.
test.service: ConditionACPower=|false failed.
test.service: ConditionKernelVersion=>=5.1 succeeded.
test.service: ConditionKernelVersion=!<4.0 succeeded.
Conditions succeeded.
systemd-analyze syscall-filter [GRUPPE…]
Dieser Befehl führt die in der angegebenen GRUPPE enthaltenen Systemaufrufe auf oder alle
bekannten Gruppen, falls keine Gruppen angegeben sind. Das Argument GRUPPE muss das Präfix
»@« enthalten.
systemd-analyze filesystems [GRUPPE…]
Dieser Befehl führt die in der angegebenen Dateisystemgruppe GRUPPE enthaltenen
Dateisysteme auf oder alle bekannten Gruppen, falls keine Gruppen angegeben sind. Das
Argument GRUPPE muss das Präfix »@« enthalten.
systemd-analyze calendar AUSDRUCK…
Dieser Befehl wertet wiederholende Kalenderzeitereignisse aus und normiert und berechnet,
wann sie das nächste Mal ablaufen. Dies akzeptiert die gleiche Eingabe wie die Einstellung
OnCalendar= in systemd.timer(5) und folgt der in systemd.time(7) beschriebenen Syntax.
Standardmäßig wird nur der nächste Zeitpunkt angezeigt, zu dem der Kalenderausdruck
abläuft; verwenden Sie --iterations=, um die angegebene Anzahl der nächsten Male
anzuzeigen, zu denen der Ausdruck abläuft. Jedes Mal, wenn der Ausdruck abläuft, wird ein
Zeitstempel gebildet, siehe den Unterbefehl timestamp weiter unten.
Beispiel 12. Schalttage in der näheren Zukunft anzeigen
$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
Original form: *-2-29 0:0:0
Normalized form: *-02-29 00:00:00
Next elapse: Sat 2020-02-29 00:00:00 UTC
From now: 11 months 15 days left
Iter. #2: Thu 2024-02-29 00:00:00 UTC
From now: 4 years 11 months left
Iter. #3: Tue 2028-02-29 00:00:00 UTC
From now: 8 years 11 months left
Iter. #4: Sun 2032-02-29 00:00:00 UTC
From now: 12 years 11 months left
Iter. #5: Fri 2036-02-29 00:00:00 UTC
From now: 16 years 11 months left
systemd-analyze timestamp ZEITSTEMPEL…
Dieser Befehl wertet den Zeitstempel (d.h. einen einzelnen Zeitpunkt) aus und gibt die
normalisierte Form und den Unterschied zwischen diesem Zeitstempel und jetzt aus. Der
Zeitstempel sollte daher der Syntax wie in systemd.time(7), Abschnitt »ZEITSTEMPEL
AUSWERTEN« dokumentiert folgen.
Beispiel 13. Die Auswertung von Zeitstempeln anzeigen
$ systemd-analyze timestamp yesterday now tomorrow
Original form: yesterday
Normalized form: Mon 2019-05-20 00:00:00 CEST
(in UTC): Sun 2019-05-19 22:00:00 UTC
UNIX seconds: @15583032000
From now: 1 day 9h ago
Original form: now
Normalized form: Tue 2019-05-21 09:48:39 CEST
(in UTC): Tue 2019-05-21 07:48:39 UTC
UNIX seconds: @1558424919.659757
From now: 43us ago
Original form: tomorrow
Normalized form: Wed 2019-05-22 00:00:00 CEST
(in UTC): Tue 2019-05-21 22:00:00 UTC
UNIX seconds: @15584760000
From now: 14h left
systemd-analyze timespan AUSDRUCK…
Dieser Befehl wertet die Zeitspanne (d.h. die Differenz zwischen zwei Zeitstempeln) aus
und gibt die normalisierte Form und das Äquivalent in Mikrosekunden aus. Die Zeitspanne
sollte daher der Syntax wie in systemd.time(7), Abschnitt »ZEITSPANNEN AUSWERTEN«
dokumentiert folgen. Werte ohne Einheit werden als Sekunden ausgewertet.
Beispiel 14. Die Auswertung von Zeitspannen anzeigen
$ systemd-analyze timespan 1s 300s '1year 0.000001s'
Original: 1s
μs: 1000000
Human: 1s
Original: 300s
μs: 300000000
Human: 5min
Original: 1year 0.000001s
μs: 31557600000001
Human: 1y 1us
systemd-analyze cat-config NAME|PFAD…
Dieser Befehl ist ähnlich zu systemctl cat, agiert aber auf Konfigurationsdateien. Er
kopiert den Inhalt einer Konfigurationsdatei und aller Ergänzungsdateien in die
Standardausgabe; dabei berücksichtigt es die normale Gruppe an Systemd-Verzeichnissen und
Regeln bezüglich des Vorrangs. Jedes Argument muss entweder ein absoluter Pfad
einschließlich des Präfixes (wie /etc/systemd/logind.conf oder
/usr/lib/systemd/logind.conf) oder ein Name relativ zu dem Präfix (wie
systemd/logind.conf) sein.
Beispiel 15. Anzeige der Logind-Konfiguration
$ systemd-analyze cat-config systemd/logind.conf
# /etc/systemd/logind.conf
...
[Login]
NAutoVTs=8
...
# /usr/lib/systemd/logind.conf.d/20-test.conf
… und einiges aus einem anderen Paket, das außer Kraft setzt
# /etc/systemd/logind.conf.d/50-override.conf
… und was vom Administrator, das außer Kraft setzt
systemd-analyze verify DATEI…
Dieser Befehl lädt Unit-Dateien und gibt Warnungen aus, falls irgendwelche Fehler erkannt
werden. Auf der Befehlszeile angegebene Dateien werden geladen, aber auch alle von diesen
referenzierte Units. Der Unit-Name auf der Platte kann außer Kraft gesetzt werden, indem
nach dem Dopppelpunkt ein Alias angegeben wird, ein Beispiel hierfür ist weiter unten zu
finden. Der komplette Unit-Suchpfad wird durch Kombination der Verzeichnisse für alle
Befehlzeilenargumente und dem normalen Unit-Ladepfad zusammengestellt. Die Variable
$SYSTEMD_UNIT_PATH wird unterstützt und kann zum Ersetzen oder Erweitern der
einkompilierten Gruppe von Unit-Ladepfaden verwandt werden; siehe systemd.unit(5)). Alle
Unit-Dateien, die in den in der Befehlszeile enthaltenen Verzeichnissen vorhanden sind,
werden gegenüber den in anderen Pfaden vorgezogen.
Derzeit werden die folgenden Fehler erkannt:
• unbekannte Abschnitte und Anweisungen,
• fehlende Abhängigkeiten, die zum Starten der übergegebenen Unit notwendig sind,
• in Documentation= aufgeführte Handbuchseiten, die im System nicht gefunden werden,
• in ExecStart= und ähnlichen aufgeführte Befehle, die nicht im System gefunden wurden
oder nicht ausführbar sind.
Beispiel 16. Falschgeschriebene Anweisung
$ cat ./user.slice
[Unit]
WhatIsThis=11
Documentation=man:nosuchfile(1)
Requires=different.service
[Service]
Description=x
$ systemd-analyze verify ./user.slice
[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
[./user.slice:13] Unknown section 'Service'. Ignoring.
Error: org.freedesktop.systemd1.LoadFailed:
Unit different.service failed to load:
No such file or directory.
Failed to create user.slice/start: Invalid argument
user.slice: man nosuchfile(1) command failed with code 16
Beispiel 17. Fehlende Dienste-Units
$ tail ./a.socket ./b.socket
==> ./a.socket <==
[Socket]
ListenStream=100
==> ./b.socket <==
[Socket]
ListenStream=100
Accept=yes
$ systemd-analyze verify ./a.socket ./b.socket
Service a.service not loaded, a.socket cannot be started.
Service b@0.service not loaded, b.socket cannot be started.
Beispiel 18. Alias für eine Unit
$ cat /tmp/source
[Unit]
Description=Hostname printer
[Service]
Type=simple
ExecStart=/usr/bin/echo %H
MysteryKey=true
$ systemd-analyze verify /tmp/source
Failed to prepare filename /tmp/source: Invalid argument
$ systemd-analyze verify /tmp/source:alias.service
/tmp/systemd-analyze-XXXXXX/alias.service:7: Unknown key name 'MysteryKey' in section 'Service', ignoring.
systemd-analyze security [UNIT…]
Dieser Befehl analysiert die Sicherheits- und Sandbox-Einstellungen einer oder mehrerer
angegebener Units. Falls mindestens ein Unit-Name angegeben ist, werden die
Sicherheitseinstellungen der angegebenen Dienste-Units untersucht und eine detaillierte
Analyse angezeigt. Falls kein Unit-Name angegeben ist, werden alle derzeit geladenen,
langlaufenden Dienste-Units untersucht und eine knappe Tabelle mit den Ergebnissen
angezeigt. Der Befehl prüft auf verschiedene sicherheitsbezogene Diensteeinstellungen,
weist jeder einen »Gefährdungsstufen«-Wert zu, abhängig davon, wie wichtig die Einstellung
ist. Dann berechnet es eine Gesamtgefährdungsstufe für die gesamte Unit, die eine
Abschätzung im Bereich 0.0…10.0 ist und anzeigt, wie aus Sicherheitssicht ein Dienst
gefährdet ist. Hohe Gefährdungsstufen deuten an, dass Sandboxing nur im geringen Umfang
verwandt wird. Geringe Gefährdungsstufen deuten an, dass enges Sandboxing und stärkste
Sicherheitsbeschränkungen angewandt werden. Beachten Sie, dass dies nur die
Sicherheitsfunktionalitäten pro Dienst analysiert, die Systemd selbst implementiert. Das
bedeutet, dass sämtliche zusätzlichen Sicherheitsmechanismen, die vom Dienste-Code selbst
erbracht werden, nicht berücksichtigt werden. Die auf diese Art bestimmte Gefährdungsstufe
sollte nicht missverstanden werden: eine hohe Gefährdungsstufe bedeutet weder, dass vom
Dienste-Code selbst kein wirksames Sandboxing angewandt wird, noch dass der Dienst
tatsächlich für lokale Angriffe oder solche aus der Ferne verwundbar ist. Hohe
Gefährdungsstufen deuten allerdings an, dass der Dienst am wahrscheinlichsten von
zusätzlichen Einstellungen für sie Nutzen ziehen würde.
Bitte beachten Sie, dass viele der Sicherheits- und Sandboxing-Einstellungen jeweils
einzeln umgangen werden können — außer sie werden mit anderen kombiniert. Falls ein Dienst
beispielsweise das Privileg behält, Einhängepunkte zu etablieren oder rückgängig zu
machen, können viele der Sandboxing-Optionen durch den System-Code selbst rückgängig
gemacht werden. Daher ist es wesentlich, dass jeder Dienst die umfassendsten und
strengsten Sicherheits- und Sandboxing-Einstellungen, die möglich sind, verwendet. Das
Werkzeug wird einige dieser Kombinationen und Beziehungen zwischen den Einstellungen
berücksichtigen, aber nicht alle. Beachten Sie auch, dass die Sicherheits- und
Sandboxing-Einstellungen, die hier analysiert werden, nur für vom Dienste-Code selbst
ausgeführte Aktionen greifen. Falls ein Dienst Zugriff auf ein IPC-System (wie D-Bus) hat,
könnte er Aktionen von anderen Diensten erbitten, die nicht den gleichen Beschränkungen
unterliegen. Daher ist jede umfassende Sicherheits- und Sandboxing-Analyse unvollständig,
falls die IPC-Zugriffsregeln nicht auch gegengeprüft werden.
Beispiel 19. systemd-logind.service analysieren
$ systemd-analyze security --no-pager systemd-logind.service
NAME DESCRIPTION EXPOSURE
✗ PrivateNetwork= Service has access to the host's network 0.5
✗ User=/DynamicUser= Service runs as root user 0.4
✗ DeviceAllow= Service has no device ACL 0.2
✓ IPAddressDeny= Service blocks all IP address ranges
…
→ Overall exposure level for systemd-logind.service: 4.1 OK 🙂
systemd-analyze inspect-elf DATEI…
Dieser Befehl wird die angegebenen Datei(en) laden, falls sie ELF-Objekte (Programme,
Bibliotheken, Speicherauszugdateien usw.) sind wird es die eingebetteten
Paketierungsmetadaten auswerten, falls vorhanden, und sie in einer Tabelle im JSON-Format
ausgeben. Siehe die Dokumentation Metadaten-Paketierung[1] für weitere Informationen.
Beispiel 20. Tabellenausgabe
$ systemd-analyze inspect-elf --json=pretty /tmp/core.fsverity.1000.f77dac5dc161402aa44e15b7dd9dcf97.58561.1637106137000000
{
"elfType" : "coredump",
"elfArchitecture" : "AMD x86-64",
"/home/bluca/git/fsverity-utils/fsverity" : {
"type" : "deb",
"name" : "fsverity-utils",
"version" : "1.3-1",
"buildId" : "7c895ecd2a271f93e96268f479fdc3c64a2ec4ee"
},
"/home/bluca/git/fsverity-utils/libfsverity.so.0" : {
"type" : "deb",
"name" : "fsverity-utils",
"version" : "1.3-1",
"buildId" : "b5e428254abf14237b0ae70ed85fffbb98a78f88"
}
}
OPTIONEN
Die folgenden Optionen werden verstanden:
--system
Agiert auf der System-Systemd-Instanz. Dies ist die implizierte Vorgabe.
--user
Agiert auf der Benutzer-Systemd-Instanz.
--global
Agiert auf der systemweiten Konfiguration für Benutzer-Systemd-Instanzen.
--order, --require
Wählt bei der Verwendung mit dem Befehl dot (siehe oben) die im Abhängigkeitsgraph zu
zeigenden Abhängigkeiten aus. Falls --order übergeben wird, werden nur Abhängigkeiten
vom Typ After= oder Before= gezeigt. Falls --require übergeben wird, werden nur
Abhängigkeiten vom Typ Requires=, Requisite=, Wants= und Conflicts= gezeigt. Falls
keines davon übergeben wird, werden die Abhängigkeiten aller dieser Typen gezeigt.
--from-pattern=, --to-pattern=
Wählt bei der Verwendung mit dem Befehl dot (siehe oben) aus, welche Beziehungen im
Abhängigkeitsgraph gezeigt werden. Beide Optionen benötigen ein glob(7)-Muster als
Argument, das mit den Knoten auf der rechten bzw. linken Seite einer Beziehung
übereinstimmen muss.
Jeder davon kann mehr als einmal verwandt werden, dann müssen die Unit-Namen auf jeden
der Werte passen. Falls Tests für beide Seiten der Relation vorhanden sind, muss eine
Relation beide Tests bestehen, um angezeigt zu werden. Wenn Muster zudem als
positionsabhängige Argumente angegeben werden, müssen sie auf mindestens einer Seite
der Relation passen. Mit anderen Worten, Muster, die mit diesen zwei Optionen
angegeben werden, verkürzen die Liste der Kanten, auf die die positionsabhängigen
Argumente passen, falls welche angegeben werden, und zeigen die komplette Liste der
Kanten andernfalls.
--fuzz=Zeitspanne
Zeigt bei der Verwendung mit dem Befehl critical-chain (siehe oben) auch Units, die
sich eine Zeitspanne früher beendeten, als die letzte Unit auf der gleichen Stufe. Die
Einheit von Zeitspanne ist Sekunden, außer es wird eine andere Einheit angegeben, z.B.
»50ms«.
--man=no
Ruft man(1) nicht auf, um die Existenz von in Documentation= aufgeführten
Handbuchseiten zu überprüfen.
--generators
Ruft Unit-Generatoren auf, siehe systemd.generator(7). Einige Generatoren benötigen
Root-Rechte. Beim Betrieb mit aktivierten Generatoren kommt es als normaler Benutzer
im Allgemeinen zu einigen Warnmeldungen.
--recursive-errors=MODUS
Steuert die Überprüfung von Units und ihrere Abhängigkeiten und ob systemd-analyze
verify sich mit einem von Null verschiedenen Exit-Status beenden soll oder nicht. Mit
yes wird ein von Null verschiedener Prozess-Exit-Status zurückgeliefert, wenn während
der Überprüfung von entweder der angegebenen Unit oder einer ihrer zugeordneten
Abhängigkeiten Warnungen auftreten. Mit no wird wird ein von Null verschiedener
Prozess-Exit-Status zurückgeliefert, wenn Warnungen während der Überprüfung nur der
angegebenen Unit auftreten. Mit one wird ein von Null verschiedener
Prozess-Exit-Status zurückgeliefert, wenn entweder bei der angegebenen Unit oder
seiner direkten Abhängigkeit Warnungen auftreten Falls dies Option nicht angegegeben
ist, wird Null als Exit-Status zurückgegeben, unabhängig davon, ob während der
Überprüfung Warnungen auftraten oder nicht.
--root=PFAD
Agiert mit cat-files und verify auf Dateien unterhalb des angegebenen Wurzelpfades
PFAD.
--image=PFAD
Agiert mit cat-files und verify auf Dateien innerhalb des angebebenen Abbildpfades
PFAD.
--offline=LOGISCH
Führt mit security eine Offline-Sicherheitsüberprüfung der angegebenen Unit-Datei(en)
durch, d.h. verlässt sich nicht auf PID 1, um Sicherheitsinformationen für die Dateien
zu erlangen, wie es der Unterbefehl security alleine tut. Dies bedeutet, dass
--offline= auch mit --root= und --image= verwandt werden kann. Falls das
Offenlegungs-Niveau einer Unit oberhalb des mit --threshold= gesetzten ist
(Standardwert 100), wird --offline= einen Fehler zurückliefern.
--profile=PFAD
Berücksichtigt mit security --offline= beim Zugriff auf die Einstellungen der Unit(s)
die angegeben portablen Profile. Das Profil kann als Name übergeben werden, wodurch
die gut bekannten Systemorte durchsucht werden, oder es kann der vollständige Pfad zu
einer angegebenen Ergänzungsdatei sein.
--threshold=WERT
Erlaubt mit security dem Benutzer einen angepassten Wert zu setzen, mit dem das
Gesamtoffenlegungsniveau für die angegebenen Unit-Datei(en) verglichen wird. Falls das
Offenlegungsniveau einer Unit größer als das vom Benutzer gesetzte ist, wird security
einen Fehler zurückliefern. --threshold= kann auch mit --offline= verwandt werden und
sein Vorgabewert ist 100.
--security-policy=PFAD
Erlaubt es mit security dem Benutzer, eine angepasste Gruppe an Anforderungen, die als
JSON-Datei formatiert ist, zu definieren, mit der die angegebenen Unit-Datei(en)
verglichen werden und ihr Gesamt-Offenlegungsniveau im Hinblick auf
Sicherheitsbedrohungen bestimmt wird.
Tabelle 1. Akzeptierte Bewertungs-Testkennzeichner
┌─────────────────────────────────────────────────────────┐
│Bewertungs-Testkennzeichner │
├─────────────────────────────────────────────────────────┤
│UserOrDynamicUser │
├─────────────────────────────────────────────────────────┤
│SupplementaryGroups │
├─────────────────────────────────────────────────────────┤
│PrivateMounts │
├─────────────────────────────────────────────────────────┤
│PrivateDevices │
├─────────────────────────────────────────────────────────┤
│PrivateTmp │
├─────────────────────────────────────────────────────────┤
│PrivateNetwork │
├─────────────────────────────────────────────────────────┤
│PrivateUsers │
├─────────────────────────────────────────────────────────┤
│ProtectControlGroups │
├─────────────────────────────────────────────────────────┤
│ProtectKernelModules │
├─────────────────────────────────────────────────────────┤
│ProtectKernelTunables │
├─────────────────────────────────────────────────────────┤
│ProtectKernelLogs │
├─────────────────────────────────────────────────────────┤
│ProtectClock │
├─────────────────────────────────────────────────────────┤
│ProtectHome │
├─────────────────────────────────────────────────────────┤
│ProtectHostname │
├─────────────────────────────────────────────────────────┤
│ProtectSystem │
├─────────────────────────────────────────────────────────┤
│RootDirectoryOrRootImage │
├─────────────────────────────────────────────────────────┤
│LockPersonality │
├─────────────────────────────────────────────────────────┤
│MemoryDenyWriteExecute │
├─────────────────────────────────────────────────────────┤
│NoNewPrivileges │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SYS_ADMIN │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SET_UID_GID_PCAP │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SYS_PTRACE │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SYS_TIME │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_NET_ADMIN │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SYS_RAWIO │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SYS_MODULE │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_AUDIT │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SYSLOG │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SYS_NICE_RESOURCE │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_MKNOD │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_CHOWN_FSETID_SETFCAP │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_DAC_FOWNER_IPC_OWNER │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_KILL │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_NET_BIND_SERVICE_BROADCAST_RAW │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SYS_BOOT │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_MAC │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_LINUX_IMMUTABLE │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_IPC_LOCK │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SYS_CHROOT │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_BLOCK_SUSPEND │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_WAKE_ALARM │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_LEASE │
├─────────────────────────────────────────────────────────┤
│CapabilityBoundingSet_CAP_SYS_TTY_CONFIG │
├─────────────────────────────────────────────────────────┤
│UMask │
├─────────────────────────────────────────────────────────┤
│KeyringMode │
├─────────────────────────────────────────────────────────┤
│ProtectProc │
├─────────────────────────────────────────────────────────┤
│ProcSubset │
├─────────────────────────────────────────────────────────┤
│NotifyAccess │
├─────────────────────────────────────────────────────────┤
│RemoveIPC │
├─────────────────────────────────────────────────────────┤
│Delegate │
├─────────────────────────────────────────────────────────┤
│RestrictRealtime │
├─────────────────────────────────────────────────────────┤
│RestrictSUIDSGID │
├─────────────────────────────────────────────────────────┤
│RestrictNamespaces_user │
├─────────────────────────────────────────────────────────┤
│RestrictNamespaces_mnt │
├─────────────────────────────────────────────────────────┤
│RestrictNamespaces_ipc │
├─────────────────────────────────────────────────────────┤
│RestrictNamespaces_pid │
├─────────────────────────────────────────────────────────┤
│RestrictNamespaces_cgroup │
├─────────────────────────────────────────────────────────┤
│RestrictNamespaces_uts │
├─────────────────────────────────────────────────────────┤
│RestrictNamespaces_net │
├─────────────────────────────────────────────────────────┤
│RestrictAddressFamilies_AF_INET_INET6 │
├─────────────────────────────────────────────────────────┤
│RestrictAddressFamilies_AF_UNIX │
├─────────────────────────────────────────────────────────┤
│RestrictAddressFamilies_AF_NETLINK │
├─────────────────────────────────────────────────────────┤
│RestrictAddressFamilies_AF_PACKET │
├─────────────────────────────────────────────────────────┤
│RestrictAddressFamilies_OTHER │
├─────────────────────────────────────────────────────────┤
│SystemCallArchitectures │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_swap │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_obsolete │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_clock │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_cpu_emulation │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_debug │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_mount │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_module │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_raw_io │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_reboot │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_privileged │
├─────────────────────────────────────────────────────────┤
│SystemCallFilter_resources │
├─────────────────────────────────────────────────────────┤
│IPAddressDeny │
├─────────────────────────────────────────────────────────┤
│DeviceAllow │
├─────────────────────────────────────────────────────────┤
│AmbientCapabilities │
└─────────────────────────────────────────────────────────┘
Siehe die nachfolgende beispielhafte »JSON-Richtlinie«.
--json=MODUS
Erstellt mit dem Befehl security eine JSON-formatierte Ausgabe der
Sicherheitsanalysetabelle. Das Format ist ein JSON-Feld mit Objekten, die die
folgenden Fehler enthalten: set (zeigt an, ob die Einstellung aktiviert wurde oder
nicht), name (damit wird auf die Einstellung Bezug genommen), json_field
(JSON-kompatible Kennung der Einstellung), description (Kurzfassung des Zustands der
Einstellung) und exposure (eine Zahl im Bereich 0.0…10.0, wobei eine höhere Zahl einer
höheren Sicherheitsbedrohung entspricht). Die JSON-Version der Tabelle wird auf die
Standardausgabe ausgegeben. Der an die Option übergebene MODUS kann einer der drei
folgenden sein: off (die Vorgabe), pretty und short, die eine verschönerte bzw.
gekürzte JSON-Version der Sicherheitstabelle ausgeben.
--iterations=ANZAHL
Zeigt bei der Verwendung zusammen mit dem Befehl calendar die angegebene Anzahl an
Iterationen, zu denen die angegebenen Kalenderausdrücke das nächste Mal ablaufen.
Standardmäßig 1.
--base-time=ZEITSTEMPEL
Zeigt bei der Verwendung zusammen mit dem Befehl calendar die nächste Iteration
relativ zum angegebenen Zeitpunkt an. Falls nicht angegeben, ist die Vorgabe die
aktuelle Zeit.
--unit=UNIT
Wertet bei der Verwendung mit dem Befehl condition alle Zuweisungen Condition*=… und
Assert*=… in der angegebenen Unit-Datei aus. Der komplette Unit-Suchpfad wird durch
Kombination der Verzeichnisse für die angegebene Unit mit dem normalen Unit-Ladepfad
zusammengestellt. Die Variable $SYSTEMD_UNIT_PATH wird unterstützt und kann zum
Ersetzen oder Erweitern der einkompilierten Gruppe von Unit-Ladepfaden verwandt
werden; siehe systemd.unit(5)). Alle Unit-Dateien, die in dem Verzeichnissen vorhanden
sind, das die angegegebene Unit enthält, werden gegenüber den in anderen Pfaden
vorgezogen.
-H, --host=
Führt die Aktion aus der Ferne aus. Geben Sie den Rechnernamen oder einen
Benutzernamen und Rechnernamen (getrennt durch »@«) an, zu dem verbunden werden soll.
Dem Rechnernamen darf optional ein Port, auf dem SSH auf Anfragen wartet, getrennt
durch »:« und dann ein Container auf dem angegebenen Host angehängt werden, womit
direkt zu einem bestimmten Container auf dem angegebenen Rechner verbunden wird. Dies
verwendet SSH, um mit der Maschinen-Verwalterinstanz auf dem Rechner in der Ferne zu
kommunizieren. Container-Namen dürfen mit machinectl -H RECHNER aufgezählt werden.
Stellen Sie IPv6-Adressen in Klammern.
-M, --machine=
Führt die Aktion in einem lokalen Container aus. Geben Sie den Namen des Containers
an, zu dem verbunden werden soll. Optional kann diesem ein Benutzername, abgetrennt
durch ein »@«-Zeichen, als der verbunden werden soll, vorangestellt werden. Falls die
besondere Zeichenkette ».host« anstelle des Container-Names verwandt wird, wird eine
Verbindung zu dem lokalen System aufgebaut (das ist nützlich, um sich zu dem
Benutzerbus eines bestimmten Benutzers zu verbinden: »--user --machine=lennart@.host«.
Falls die »@«-Syntax nicht verwandt wird, wird die Verbindung als Benutzer »root«
vorgenommen. Falls die »@«-Syntax verwandt wird, kann entweder die linke oder die
rechte Seite fortgelassen werden (aber nicht beide). In diesem Fall wird der lokale
Benutzername und ».host« angenommen.
--quiet
Unterdrückt Hinweise und andere nicht wesentliche Ausgaben.
-h, --help
Zeigt einen kurzen Hilfetext an und beendet das Programm.
--version
Zeigt eine kurze Versionszeichenkette an und beendet das Programm.
--no-pager
Leitet die Ausgabe nicht an ein Textanzeigeprogramm weiter.
EXIT-STATUS
Bei Erfolg wird 0 zurückgegeben, anderenfalls ein Fehlercode ungleich Null.
UMGEBUNGSVARIABLEN
$SYSTEMD_LOG_LEVEL
Die maximale Protokollierstufe ausgesandter Nachrichten (Nachrichten mit einer höheren
Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Sie muss (in
absteigender Reihenfolge) entweder alert, crit, err, warning, notice, info, debug oder
eine Ganzzahl im Bereich 0…7 sein. Siehe syslog(3) für weitere Informationen.
$SYSTEMD_LOG_COLOR
Ein logischer Wert. Falls wahr, werden auf das TTY geschriebene Nachrichten gemäß
ihrer Priorität eingefärbt.
Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal
geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen,
selbständig Nachrichten gemäß ihrer Protokollierungsstufe einfärben.
$SYSTEMD_LOG_TIME
Ein logischer Wert. Falls wahr, wird den Protokollnachrichten der Konsole ein
Zeitstempel vorangestellt.
Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal oder
in eine Datei geschrieben werden, da journalctl(1) und andere Werkzeuge, die
Protokolle anzeigen, selbständig Zeitstempel basierend auf ihren Metadaten den
Nachrichten anhängen werden.
$SYSTEMD_LOG_LOCATION
Ein logischer Wert. Falls wahr, wird den Protokollnachrichten ein Dateinamen und eine
Zeilenummer in dem Quellcode, aus dem die Nachrichten stammen, vorangestellt.
Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den
Journal-Einträgen angehängt ist. Die Aufnahme in den Nachrichtentext kann bei der
Fehlersuche in Programmen dennoch praktisch sein.
$SYSTEMD_LOG_TID
Ein logischer Wert. Falls wahr, wird den Nachrichten die aktuelle numerische
Thread-Kennung (TID) vorangestellt.
Beachten Sie, dass diese Informationen sowieso als Metadatan an Journal-Einträge
angehängt wird. Die Aufnahme direkt im Nachrichtentext kann aber trotzdem bei der
Fehlersuche in Programmen praktisch sein.
$SYSTEMD_LOG_TARGET
Das Ziel für Protokolliernachrichten. Entweder console (auf das angehängte TTY
protokollieren), console-prefixed (auf das angehängte TTY protokollieren, aber die
Protokollierstufe und »Einrichtung« voranstellen, siehe syslog(3)), kmsg (in den
zirkulären Kernel-Protokollpuffer protokollieren), journal (in das Journal
protokollieren (journal-or-kmsg (in das Journal protokollieren, falls verfügbar, und
andernfalls nach Kmsg), auto (das geeignete Protokollierziel automatisch ermitteln,
die Vorgabe) oder null (die Protokollierung deaktivieren).
$SYSTEMD_PAGER
Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist; setzt $PAGER
außer Kraft. Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe
wohlbekannter Textanzeigeprogrammimplementierungen der Reihe nach ausprobiert,
einschließlich less(1) und more(1), bis eines gefunden wird. Falls keine
Textanzeigeprogrammimplementierung gefunden wird, wird keines aufgerufen. Setzen der
Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist äquivalent zur
Übergabe von --no-pager.
Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird $SYSTEMD_PAGER
(sowie $PAGER) ohne Rückmeldung ignoriert.
$SYSTEMD_LESS
Setzt die an less übergebenen Optionen (standardmäßig »FRSXMK«) außer Kraft.
Benutzer könnten insbesondere zwei Optionen ändern wollen:
K
Diese Option weist das Textanzeigeprogramm an, sich sofort beim Druck von Strg-C
zu beenden. Um less die Handhabung von Strg-C selbst zum Umschalten auf die
Eingabeaufforderung zu erlauben, setzen Sie diese Option zurück.
Falls der Wert von $SYSTEMD_LESS kein »K« enthält und less das aufgerufene
Textanzeigeprogramm ist, wird Strg+C durch das Programm ignoriert und muss durch
das Textanzeigeprogramm selbst gehandhabt werden.
X
Diese Option weist das Textanzeigeprogramm an, keine Termcap-Initialisierungs- und
-Deinitalisierungszeichenketten an das Terminal zu senden. Dies ist standardmäßig
gesetzt, damit die Darstellung von Befehlen selbst nach dem Beenden des
Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch einige Funktionen
des Textanzeigeprogramms nicht zur Verfügung; insbesondere ist das Scrollen in der
Ausgabe mit der Maus nicht möglich.
Siehe less(1) für weitere Ausführungen.
$SYSTEMD_LESSCHARSET
Setzt den an less zu übergebenden Zeichensatz (standardmäßig »utf-8«, falls das
aufrufende Terminal als UTF-8-kompatibel erkannt wurde) außer Kraft.
$SYSTEMD_PAGERSECURE
Akzeptiert einen logischen Wert. Wenn wahr, wird der »sichere« Modus des
Seitenanzeigeprogramms verwandt, falls falsch, wird dieser deaktiviert. Falls
$SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, dann wird der sichere Modus
aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentümer der
Anmeldesitzung ist, siehe geteuid(2) und sd_pid_get_owner_uid(3). Im sicheren Modus
wird LESSSECURE=1 beim Aufruf des Seitenanzeigeprogramms gesetzt und das
Seitenanzeigeprogramm muss Befehle deaktivieren, die neue Dateien öffnen oder
erstellen oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE
überhaupt nicht gesetzt ist, werden Seitenanzeigeprogramme, bei denen unbekannt ist,
ob sie einen sicheren Modus implementieren, nicht verwandt. (Derzeit implementiert nur
less(1) einen sicheren Modus.)
Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden, beispielsweise mittels
sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen, dass
keine ungeplanten interaktiven Funktionalitäten aktiviert werden. Der »sichere« Modus
für das Seitenanzeigeprogramm kann wie oben beschrieben automatisch aktiviert werden.
Durch Setzen von SYSTEMD_PAGERSECURE=0 oder durch Nichtenfernen dieser Einstellung aus
der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige Befehle auszuführen.
Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden muss, falls die Variablen
$SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen. Es kann sinnvoll sein,
stattdessen den Seitenanzeiger komplett mit --no-pager zu deaktivieren.
$SYSTEMD_COLORS
Akzeptiert ein logisches Argument. Wenn wahr, werden systemd und verwandte
Hilfswerkzeuge Farben in ihrer Ausgabe verwenden, andernfalls wird die Ausgabe
einfarbig sein. Zusätzlich kann die Variable eine der folgenden besonderen Werte
annehmen: »16«, »256«, um die Verwendung von Farbe auf die grundlegenden 16 bzw. 256
ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf $TERM und der
vorliegenden Verbindung der Konsole basierende automatische Entscheidung außer Kraft
zu setzen.
$SYSTEMD_URLIFY
Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links für
Terminal-Emulatoren, die dies unterstützen, erstellt werden sollen. Dies kann
angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen
Bedingungen trifft, außer Kraft zu setzen.
BEISPIELE
Beispiel 21. JSON-Richtlinie
Die als Pfadparameter an --security-policy= übergebene JSON-Datei hat ein JSON-Objekt
oberster Stufe, wobei die Schlüssel die oben erwähnten Bewertungstestkennzeichner sind.
Die Werte in der Datei sollten JSON-Objekte mit einem oder mehreren der folgenden Felder
sein: description_na (Zeichenkette), description_good (Zeichenkette), description_bad
(Zeichenkette), weight (vorzeichenlose Ganzzahl) und range (vorzeichenlose Ganzzahl).
Falls eines dieser Felder, die bestimmten Kennungen der Unit-Datei entsprechen, im
JSON-Objekt fehlt, wird standardmäßig der eingebaute Vorgabefeldwert, der der gleichen
Kennung entspricht, für die Sicherheitsanalyse verwandt. Die Felder »weight« und »range«
werden zum Bestimmen der Gesamt-Offenlegungsstufe der Unit-Dateien verwandt: dem Wert
jeder Einstellung wird ein Schlechtigkeitsstand zugewiesen, der mit dem Richtliniengewicht
multipliziert und durch den Richtlinienbereich geteilt wird, um die Gesamtoffenlegung zu
bestimmen, den diese Einstellung impliziert. Die berechnete Schlechtigkeit wird über alle
Einstellungen in der Unit-Datei aufsummiert, auf den Bereich 1…100 normiert und dazu
verwandt, die Gesamtoffenlegungsstufe der Unit zu bestimmen. Indem Benutzer diese Felder
verändern können, gibt der »security«-Unterbefehl ihnen die Möglichkeit, für sich selbst
zu entscheiden, welche Kennungen wichtiger sind und daher einen größeren Effekt auf die
Offenlegungsstufe haben sollten. Ein Gewicht von »0« bedeutet, dass die Einstellung nicht
geprüft wird.
{
"PrivateDevices":
{
"description_good": "Dienst hat keinen Zugriff auf Hardware-Geräte",
"description_bad": "Dienst hat möglicherweise Zugriff auf Hardware-Geräte",
"weight": 1000,
"range": 1
},
"PrivateMounts":
{
"description_good": "Dienst kann keine Systemeinhängungen installieren",
"description_bad": "Dienst darf Systemeinhängungen installieren",
"weight": 1000,
"range": 1
},
"PrivateNetwork":
{
"description_good": "Dienst hat keinen Zugriff auf das Netzwerk des Rechners",
"description_bad": "Dienst hat Zugriff auf das Netzwerk des Rechners",
"weight": 2500,
"range": 1
},
"PrivateTmp":
{
"description_good": "Dienst hat keinen Zugriff auf die temporären Dateien anderer Software",
"description_bad": "Dienst hat Zugriff auf die temporären Dateien anderer Software",
"weight": 1000,
"range": 1
},
"PrivateUsers":
{
"description_good": "Dienst hat keinen Zugriff auf andere Benutzer",
"description_bad": "Dienst hat Zugriff auf andere Benutzer",
"weight": 1000,
"range": 1
}
}
SIEHE AUCH
systemd(1), systemctl(1)
ANMERKUNGEN
1. Metadaten-Paketierung
https://systemd.io/COREDUMP_PACKAGE_METADATA/
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.