Provided by: manpages-de_4.21.0-2_all 
BEZEICHNUNG
file-hierarchy - Dateisystemhierarchie-Überblick
BESCHREIBUNG
Betriebssysteme, die das System und den Diensteverwalter von systemd(1) verwenden, sind auf einer von
UNIX inspirierten und auf diesem basierenden Dateisystemhierarchie organisiert, genauer der in der
Spezifikation Dateisystem-Hierarchie[1] und hier(7) mit verschiedenen Erweiterungen, teilweise in der
XDG-Basisverzeichnisspezifikation[2] und XDG-Benutzerverzeichnisse[3] dokumentiert, festgelegten. Diese
Handbuchseite beschreibt die verallgemeinerte, allerdings minimale und modernisierte Untermenge dieser
Spezifikationen, die die Vorschläge und Begrenzungen, die Systemd in Bezug auf die Dateisystemhierarchie
macht, genauer definiert.
Viele der hier beschriebenen Pfade können mit dem Werkzeug systemd-path(1) abgefragt werden.
ALLGEMEINE STRUKTUR
/
Die Wurzel des Dateisystems. Normalerweise schreibbar, aber dies wird nicht benötigt. Möglicherweise
ein temporäres Dateisystem (»tmpfs«). Wird nicht mit anderen Rechnern gemeinsam benutzt (außer
nur-lesbar).
Hinzugefügt in Version 215.
/boot/
Die Systemstartpartition, wird zum Hochfahren des Systems verwandt. Auf EFI-Systemen ist dies
möglicherweise die EFI-Systempartition (ESP), siehe auch systemd-gpt-auto-generator(8). Dieses
Verzeichnis ist normalerweise streng an den lokalen Rechner gebunden und sollte als nur lesbar
betrachtet werden, außer wenn ein neuer Kernel oder ein neues Systemstartprogramm installiert wird.
Dieses Verzeichnis existiert nur auf Systemen, die auf physischer oder emulierter Hardware laufen,
die Systemstartprogramme benötigen.
Hinzugefügt in Version 215.
/efi/
Falls die Systemstartpartition /boot/ separat von der EFI-Systempartition (ESP), wird letztere hier
eingehängt. Werkzeuge, die mit der EFI-Systempartition arbeiten müssen, sollten hier zuerst unter
diesem Einhängepunkt schauen, und dann auf /boot/ zurückfallen, falls ersterer nicht geeignet ist
(falls es beispielsweise kein Einhängepunkt ist oder nicht den korrekten Dateisystemtyp
MSDOS_SUPER_MAGIC hat).
Hinzugefügt in Version 239.
/etc/
Systemspezifische Konfiguration. Dieses Verzeichs kann, muss aber nicht nur lesbar sein. Häufig wird
dieses System vorab mit vom Lieferanten bereitgestellten Konfigurationsdateien befüllt, aber
Anwendungen sollten keine Annahmen darüber treffen, ob dieses Verzeichnis voll oder überhaupt befüllt
ist, und sollten auf Vorgaben zurückfallen, falls die Konfiguration fehlt.
Hinzugefügt in Version 215.
/home/
Der Ort für die Home-Verzeichnisse der normalen Benutzer. Möglicherweise von mehreren Systemen
gemeinsam benutzt und niemals nur lesbar. Dieses Verzeichnis sollte nur für normale Benutzer verwandt
werden, niemals für Systembenutzer. Dieses Verzeichnis und möglicherweise die darin enthaltenen
Verzeichnisse könnten erst spät im Systemstartprozess oder sogar erst nach der Benutzeranmeldung
verfügbar werden. Dieses Verzeichnis kann auf Netzwerkdateisystemen mit eingeschränkter
Funktionalität abgelegt werden, daher sollten Anwendungen nicht davon ausgehen, dass die komplette
Menge der Datei-APIs für dieses Verzeichnis verfügbar ist. Anwendungen sollten im Allgemeinen dieses
Verzeichnis nicht direkt referenzieren, sondern über die pro Benutzer gültige Umgebungsvariable $HOME
oder über das Home-Verzeichnisfeld der Benutzerdatenbank.
Hinzugefügt in Version 215.
/root/
Das Home-Verzeichnis des Benutzers root. Das Home-Verzeichnis des Benutzers root liegt außerhalb von
/home/, um sicherzustellen, dass der Benutzer root sich selbst dann anmelden kann, wenn /home/ nicht
verfügbar und eingehängt ist.
Hinzugefügt in Version 215.
/srv/
Der Ort, an dem allgemeine Server-Nutzdaten gespeichert werden, verwaltet vom Administrator. Es gibt
keine Einschränkungen, wie dieses Verzeichnis intern organisiert wird. Im Allgemeinen schreibbar und
möglicherweise von mehreren Systemen gemeinsam genutzt. Dieses Verzeichnis könnte erst spät während
des Systemstarts verfügbar oder schreibbar werden.
Hinzugefügt in Version 215.
/tmp/
Der Ort für kleine, temporäre Dateien. Dieses Verzeichnis wird normalerweise als »tmpfs«-Instanz
eingehängt und sollte daher nicht für größere Dateien verwandt werden. (Verwenden Sie /var/tmp/ für
größere Dateien.) Dieses Verzeichnis wird normalerweise beim Systemstart geleert. Es können auch
Dateien, auf die innerhalb einer bestimmten Zeit nicht zugegriffen wurde, automatisch gelöscht
werden.
Falls Anwendungen die gesetzte Umgebungsvariable $TMPDIR finden, sollten Sie das darin festgelegte
Verzeichnis statt /tmp/ verwenden (siehe environ(7) und IEEE Std 1003.1[4] für Details).
Da auf /tmp/ von anderen Benutzern des Systems aus zugegriffen werden kann, ist es wesentlich, dass
Dateien und Unterverzeichnisse unter diesem Verzeichnis nur mit mkstemp(3), mkdtemp(3) und ähnlichen
Aufrufen erstellt werden. Für weitere Details siehe Sichere Verwendung von /tmp/ und /var/tmp/[5].
Hinzugefügt in Version 215.
LAUFZEITDATEN
/run/
Ein Dateisystem »tmpfs«, in das Systempakete Laufzeitdaten,Socket-Dateien und ähnliches ablegen
können. Dieses Verzeichnis wird beim Systemstart bereinigt und ist im Allgemeinen nur für
privilegierte Programme schreibbar. Immer schreibbar.
Hinzugefügt in Version 215.
/run/log/
Laufzeitsystemprotokolle. Systemkomponenten können private Protokolle in diesem Verzeichnis ablegen.
Immer schreibbar, selbst wenn /var/log/ noch nicht zugreifbar sein sollte.
Hinzugefügt in Version 215.
/run/user/
Enthält benutzerbezogene Laufzeitverzeichnisse, jede normalerweise individuell als Instanz »tmpfs«
eingehängt. Immer schreibbar, wird bei jedem Systemstart und wenn sich der Benutzer abmeldet
bereinigt. Benutzer-Code sollte dieses Verzeichnis nicht direkt sondern mittels der
Umgebungsvariablen $XDG_RUNTIME_DIR referenzieren, wie dies in der
XDG-Basisverzeichnisspezifikation[2] dokumentiert ist.
Hinzugefügt in Version 215.
VOM LIEFERANTEN BEREITGESTELLTE BETRIEBSSYSTEMRESSOURCEN
/usr/
Vom Lieferanten bereitgestellte Betriebssystemressourcen. Normalerweise nur lesbar, aber dies ist
nicht zwingend. Möglicherweise von mehreren Rechnern gemeinsam benutzt. Dieses Verzeichnis sollte vom
Administrator nicht verändert werden, außer bei der Installation oder Entfernung von Paketen, die vom
Lieferanten bereitgestellt wurden.
Hinzugefügt in Version 215.
/usr/bin/
Ausführbare und Binärprogramme für Benutzerbefehle, die im Suchpfad $PATH auftauchen sollen. Es wird
empfohlen, in diese Verzeichnisse nur Programme abzulegen, die sinnvollerweise aus einer Shell
aufgrufen werden können (z.B. keine Daemon-Programme); andere Programme sollten stattdessen in
Unterverzeichnissen von /usr/lib/ abgelegt werden.
Hinzugefügt in Version 215.
/usr/include/
C- und C++-API-Header-Dateien von Systembibliotheken.
Hinzugefügt in Version 215.
/usr/lib/
Statische, private Daten des Lieferanten, die zu allen Architekturen kompatibel sind (aber nicht
notwendigerweise architekturunabhängig). Beachten Sie, dass dies interne Programme oder andere
Programme, die nicht typischerweise von der Shell aus aufgerufen werden, beinhaltet. Solche Programme
können für jede vom System unterstützte Architektur sein. Legen Sie in dieses Verzeichnis keine
öffentlichen Bibliotheken, verwenden Sie stattdessen $libdir (siehe unten).
Hinzugefügt in Version 215.
/usr/lib/Arch-Kennung/
Ort zur Ablage dynamischer Bibliotheken, auch $libdir benannt. Die zu verwendende Architekturkennung
ist in der Liste Multiarch-Architekturkennungen (Tupel)[6] definiert. Veraltete Orte für $libdir sind
/usr/lib/, /usr/lib64/. Dieses Verzeichnis sollte nicht für paketspezifische Daten verwandt werden,
außer diese Daten sind auch architekturabhängig. Um $libdir bezüglich der primären Architektur des
Systems abzufragen, rufen Sie Folgendes auf:
# systemd-path system-library-arch
Hinzugefügt in Version 215.
/usr/share/
Von mehreren Paketen gemeinsam benutzte Ressourcen, wie Dokumentation, Handbuchseiten,
Zeitzoneninformationen, Schriften und andere Ressourcen. Normalerweise unterliegt der genaue Ort und
das Format der unterhalb dieses Verzeichnisses gespeicherten Dateien Vorgaben, die die
Interoperabilität sicherstellen.
Hinzugefügt in Version 215.
/usr/share/doc/
Dokumentation für das Betriebssystem oder Systempakete.
Hinzugefügt in Version 215.
/usr/share/factory/etc/
Depot für durch Lieferanten bereitgestellte Vorgabekonfigurationsdateien. Dieses Verzeichnis sollte
mit unverfälschten Versionen sämtlicher vom Lieferanten bereitgestellten Konfigurationsdateien, die
in /etc/ abgelegt werden könnten, bestückt werden. Dies ist nützlich, um die lokale Konfiguration
eines Systems mit den Vorgaben des Lieferanten zu vergleichen und die lokalen Konfigurationen mit den
Vorgaben zu bestücken.
Hinzugefügt in Version 215.
/usr/share/factory/var/
Ähnlich /usr/share/factory/etc/, aber für Lieferantenversionen von Dateien in dem variablen,
dauerhaften Datenverzeichnis /var/.
Hinzugefügt in Version 215.
DAUERHAFTE VARIABLE SYSTEMDATEN
/var/
Dauerhafte, variable Systemdaten. Während des normalen Betriebs des Systems beschreibbar. Dieses
Verzeichnis kann mit vom Lieferanten bereitgestellten Daten vorbestückt sein, aber Anwendungen
sollten in der Lage sein, notwendige Dateien und Verzeichnisse in dieser Unterhierarchie wieder
herzustellen, falls sie fehlen, da das System hochfahren könnte, ohne dass dieses Verzeichnis
bestückt ist. Dauerhaftigkeit wird empfohlen, ist aber optional, um kurzlebige Systeme zu
unterstützen. Dieses Verzeichnis könnte erst spät beim Systemstart verfügbar oder schreibbar werden.
Komponenten, die für den Betrieb während der frühen Systemstartphase benötigt werden, dürfen daher
nicht bedingungslos von diesem Verzeichnis abhängen.
Hinzugefügt in Version 215.
/var/cache/
Dauerhafte Systemzwischenspeicherdaten. Systemkomponenten können entbehrliche Daten in dieses
Verzeichnis ablegen. Entleerung dieses Verzeichnisses sollte keine Auswirkung auf den Betrieb von
Programmen haben, außer für erhöhte Laufzeit, notwendig, um diese Zwischenspeicher neu aufzubauen.
Hinzugefügt in Version 215.
/var/lib/
Dauerhafte Systemdaten. Systemkomponenten können private Daten in dieses Verzeichnis ablegen.
Hinzugefügt in Version 215.
/var/log/
Dauerhafte Systemprotokolle. Systemkomponenten können private Protokolle in dieses Verzeichnis
ablegen, allerdings wird empfohlen, den Großteil der Protokollierung über Aufrufe von syslog(3) und
sd_journal_print(3) durchzuführen.
Hinzugefügt in Version 215.
/var/spool/
Dauerhafte System-Spool-Daten, wie Drucker- oder E-Mail-Warteschlangen.
Hinzugefügt in Version 215.
/var/tmp/
Der Ort für größere und dauerhafte temporäre Dateien. Im Gegensatz zu /tmp/ wird in dieses
Verzeichnis normalerweise ein dauerhaftes physisches Dateisystem eingehängt und kann größere Dateien
akzeptieren. (Verwenden Sie /tmp für kleinere, kurzlebigere Dateien.) Dieses Verzeichnis wird
typischerweise beim Systemstart nicht bereinigt, aber zeitbasiertes Aufräumen von Dateien, auf die in
einer bestimmten Zeit nicht zugegriffen wurde, wird durchgeführt.
Falls Anwendungen erkennen, dass die Variable $TMPDIR gesetzt ist, sollten sie das darin festgelegte
Verzeichnis gegenüber Referenzen auf /var/tmp bevorzugen (siehe environ(7) für Details).
Es gelten die gleichen Sicherheitseinschränkungen wie bei /tmp: mkstemp(3), mkdtemp(3) und ähnliche
Aufrufe sollten verwandt werden. Für weitere Details über dieses Verzeichnis, siehe Sichere
Verwendung von /tmp und /var/tmp[5].
Hinzugefügt in Version 215.
VIRTUELLE KERNEL- UND API-DATEISYSTEME
/dev/
Das Wurzelverzeichnis für Geräteknoten. Normalerweise wird dieses Verzeichnis als »devtmpfs«-Instanz
eingehängt, in Sandbox-/Container-Installationen kann es aber ein anderer Typ sein. Dieses
Verzeichnis wird gemeinsam vom Kernel und systemd-udevd(8) verwaltet und andere Komponenten sollten
nicht darein schreiben. Eine Reihe von virtuellen Dateisystemen für spezielle Zwecke könnten
unterhalb dieses Verzeichnisses eingehängt sein.
Hinzugefügt in Version 215.
/dev/shm/
Platz für gemeinsame Speichersegmente gemäß POSIX, wie sie von shm_open(3) erstellt werden. Dieses
Verzeichnis wird beim Systemstart entleert und ist ein »tmpfs«-Dateisystem. Da alle Benutzer in
diesem Verzeichnis Schreibrechte haben, sollte besondere Vorsicht walten gelassen werden, um
Namenskollisionen und Verwundbarkeiten zu vermeiden. Für normale Benutzer werden gemeinsam benutzte
Speichersegmente in diesem Verzeichnis normalerweise gelöscht, wenn sich der Benutzer abmeldet.
Normalerweise ist es daher eine bessere Idee, Speicher-gemappte Dateien in /run/ (für
Systemprogramme) oder in $XDG_RUNTIME_DIR (für Benutzerprogramme) statt gemeinsamen
Speichersegementen gemäß POSIX zu verwenden, da diese Verzeichnisse nicht für das gesamte System
schreibbar und daher nicht für Sicherheits-sensible Namenskollisionen verwundbar sind.
Hinzugefügt in Version 215.
/proc/
Ein virtuelles Kerneldateisystem, das die Prozesslisten und andere Funktionalitäten offenlegt. Dieses
Dateisystem ist hauptsächlich ein API als Schnittstelle für den Kernel und kein Ort, an dem normale
Dateien gespeichert werden dürfen. Für Details siehe proc(5). Eine Reihe von virtuellen Dateisystemen
für spezielle Zwecke könnten unterhalb dieses Verzeichnisses eingehängt sein.
Hinzugefügt in Version 215.
/proc/sys/
Eine Hierarchie unter /proc/, die eine Reihe von Kerneleinstellern offenlegt. Die primäre Art, die
Einstellungen in diesem API-Dateibaum zu konfigurieren, ist mittels sysctl.d(5)-Dateien. In
Sandbox-/Container-Umgebungen ist dieses Verzeichnis im Allgemeinen nur lesbar eingehängt.
Hinzugefügt in Version 215.
/sys/
Ein virtuelles Kerneldateisystem, das entdeckte Geräte und andere Funktionalitäten offenlegt. Dieses
Dateisystem ist hauptsächlich ein API, um an den Kernel zu koppeln und kein Ort, an dem normale
Dateien gespeichert werden dürfen. In Sandbox-/Container-Umgebungen ist dieses Verzeichnis im
Allgemeinen nur lesbar eingehängt. Eine Reihe von virtuellen Dateisystemen für spezielle Zwecke
könnten unterhalb dieses Verzeichnisses eingehängt sein.
Hinzugefügt in Version 215.
/sys/fs/cgroup/
Ein virtuelles Kerneldateisystem, das die Prozess-Control-Gruppen (Cgroups) offenlegt. Dieses
Dateisystem ist eine API zu Schnittstellen im Kernel und kein Ort, an dem normale Dateien gespeichert
werden dürfen. Auf aktuellen Systemen, die im Standardmodus »vereinigt« laufen, dient dieses
Verzeichnis als der Einhängepunkt für das »cgroup2«-Dateisystem, das eine vereinigte
Ggroup-Hierarchie für alle Ressourcen-Controller bereitstellt. Auf Systemen, die
nicht-Standard-Konfigurationen verwenden, darf dieses Verzeichniss stattdessen ein Tmpfs-Dateisystem
sein, das die Einhängepunkte für die verschiedenen »cgroup«- (v1-)-Ressourcen-Controller enthält; in
diesen Konfigurationen wird »cgroup2« (falls überhaupt) unter /sys/fs/cgroup/unified/ eingehängt,
aber an Cgroup2 werden keine Ressourcen-Controller angehängt. In Sandbox- oder
Container-Installationen kann dieses Verzeichnis entweder nicht existieren oder darf eine Untermenge
der Funktionalität enthalten.
Hinzugefügt in Version 251.
KOMPATIBILITÄTS-SYMLINKS
/bin/, /sbin/, /usr/sbin/
Diese Kompatibilitätssymlinks zeigen auf /usr/bin/ und stellen sicher, dass Skripte und Programme,
die diese veralteten Pfade referenzieren, korrekt ihre Programme finden.
Hinzugefügt in Version 215.
/lib/
Diese Kompatibilitätssymlinks zeigen auf /usr/lib/ und stellen sicher, dass Programme, die diesen
veralteten Pfad referenzieren, korrekt ihre Ressourcen finden.
Hinzugefügt in Version 215.
/lib64/
Auf einigen Architektur-ABIs zeigt dieser Kompatibilitätssymlink auf $libdir, um sicherzustellen,
dass Programme, die diesen veralteten Pfad referenzieren, korrekt ihre dynamischen Lader finden.
Dieser Symlink existiert nur auf Architekturen, deren ABI den dynamischen Lader in diesem Pfad
ablegt.
Hinzugefügt in Version 215.
/var/run/
Dieser Kompatibilitätssymlink zeigt auf /run/, um sicherzustellen, dass Programme, die diesen
veralteten Pfad referenzieren, korrekt ihre Laufzeitdaten finden.
Hinzugefügt in Version 215.
HOME-VERZEICHNIS
Benutzeranwendungen könnten Dateien und Verzeichnisse in dem Home-Verzeichnis des Benutzers ablegen
wollen. Dies sollte der folgenden grundlegenden Struktur folgen. Hinweis: Einige dieser Verzeichnisse
sind auch durch die XDG-Basisverzeichnisspezifikation[2] standardisiert (allerdings schwächer).
Zusätzliche Orte für abstrakte Benutzerressourcen werden durch xdg-user-dirs[3] definiert.
~/.cache/
Dauerhafte Benutzerzwischenspeicherdaten. Benutzerprogramme können entbehrliche Daten in dieses
Verzeichnis ablegen. Entleerung dieses Verzeichnisses sollte keine Auswirkung auf den Betrieb von
Programmen haben, außer eine erhöhte Laufzeit, notwendig, um diese Zwischenspeicher neu aufzubauen.
Falls eine Anwendung ein gesetztes $XDG_CACHE_HOME findet, sollte es das darin festgelegte
Verzeichnis statt dieses Verzeichnisses verwenden.
Hinzugefügt in Version 215.
~/.config/
Anwendungskonfiguration. Wenn ein neuer Benutzer erstellt wird, wird dieses Verzeichnis leer sein
oder überhaupt nicht existieren. Anwendungen sollten auf Vorgaben zurückfallen, falls ihre
Konfiguration in diesem Verzeichnis fehlt. Falls eine Anwendung ein gesetztes $XDG_CONFIG_HOME
findet, sollte es das darin festgelegte Verzeichnis statt dieses Verzeichnisses verwenden.
Hinzugefügt in Version 215.
~/.local/bin/
Programme, die im Suchpfad $PATH des Benutzers auftauchen sollen. Es wird empfohlen, in diese
Verzeichnisse nur Programme abzulegen, die sinnvollerweise aus einer Shell aufgerufen werden können;
andere Programme sollten stattdessen in Unterverzeichnissen von ~/.local/lib/ abgelegt werden. Bei
der Ablage von architekturabhängigen Programmen sollte Sie an diesem Platz Vorsicht walten lassen, da
diese problematisch sein könnten, falls das Home-Verzeichnis auf verschiedenen Rechnern mit
verschiedenen Architekturen gemeinsam benutzt wird.
Hinzugefügt in Version 215.
~/.local/lib/
Statische, private Lieferantendaten, die zu allen Architekturen kompatibel sind.
Hinzugefügt in Version 215.
~/.local/lib/Architekturkennung/
Ort zur Ablage öffentlicher dynamischer Bibliotheken. Die zu verwendende Architekturkennzeichnung ist
in der Liste Multiarch-Architekturkennungen (Tupel)[6] definiert.
Hinzugefügt in Version 215.
~/.local/share/
Ressourcen, die von mehreren Paketen gemeinsam benutzt werden, wie Schriften oder Abbildungen.
Normalerweise ist der genaue Ort und das Format der Dateien, die unterhalb dieses Verzeichnisses
gespeichert werden, abhängig von der Spezifikation, die die Interoperabilität sicherstellt. Falls
eine Anwendung ein gesetztes $XDG_DATA_HOME findet, sollte es das darin festgelegte Verzeichnis statt
dieses Verzeichnisses verwenden.
Hinzugefügt in Version 215.
~/.local/state/
Anwendungszustand. Wenn ein neuer Benutzer erstellt wird, wird dieses Verzeichnis leer sein oder
überhaupt nicht existieren. Anwendungen sollten auf Vorgaben zurückfallen, falls ihre ihr Zustand in
diesem Verzeichnis fehlt. Falls eine Anwendung ein gesetztes $XDG_STATE_HOME findet, sollte es das
darin festgelegte Verzeichnis statt dieses Verzeichnisses verwenden.
Hinzugefügt in Version 254.
SCHREIBZUGRIFF
Nicht privilegierter Schreibzugriff
Nicht privilegierten Prozessen fehlt im Allgemeinen der Schreibzugriff auf den Großteil der Hierarchie.
Die Ausnahmen für normale Benutzer sind /tmp/, /var/tmp/, /dev/shm/ sowie das Home-Verzeichnis $HOME
(normalerweise unterhalb von /home/) und das Laufzeitverzeichnis $XDG_RUNTIME_DIR (unterhalb von
/run/user/) des Benutzers, die alle schreibbar sind.
Für nicht privilegierte Systemprozesse sind nur /tmp/, /var/tmp/ und /dev/shm/ schreibbar. Falls ein
nicht privilegierter Systemprozess ein privates schreibbares Verzeichnis in /var/ oder /run/ benötigt,
wird empfohlen, es entweder vor der Abgabe von Privilegien im Daemon-Code oder es mittels
tmpfiles.d(5)-Fragementen während des Systemstarts oder mittels der Anweisungen StateDirectory= und
RuntimeDirectory= in Dienste-Units (siehe systemd.unit(5) für Details) zu erzeugen.
/tmp/, /var/tmp/ und /dev/shm/ sollten nosuid und nodev eingehängt werden, wodurch Dateien mit
set-user-id-Modus und Blockspezialgeräte auf diesen Dateisystemen nicht interpretiert werden. Im
Allgemeinen ist es nicht möglich, sie mit noexec einzuhängen, da verschiedene Programme diese
Verzeichnisse für dynamisch erstellten oder optimierten Code verwenden und mit diesem Schalter diese
Anwendungsszenarien fehlschlagen würden. Auf Spezialinstallationen oder Systemen, auf denen sämtliche
installierbare Software bekannt ist und diese Funktionalität nicht benötigt, ist die Verwendung dieses
Schalters möglich. Siehe die Diskussion von nosuid/nodev/noexec in mount(8) und PROT_EXEC in mmap(2).
Fehlen von Schreibzugriff auf schreibgeschützten Systemen und während der Systemwiederherstellung
Wie oben angemerkt arbeiten einige Systeme mit schreibgeschützten /usr- und /etc-Hierarchien,
möglicherweise wird der Schreibzugriff nur während Paket-Upgrades erlaubt. Andere Teile der Hierarchie
werden im Allgemeinen lese- und schreibbar eingehängt (insbesondere /var und /var/tmp), könnten aber
schreibgeschützt sein, wenn der Kernel die Dateisysteme in Folge eines Fehlers schreibgeschützt neu
einhängt oder wenn das System schreibgeschützt zu Wiederherstellungszwecken gestartet wird. Soweit
angemessen, sollten Anwendungen darauf vorbereitet sein, ohne Schreibzugriff zu arbeiten, so dass
beispielsweise ein Fehler beim Schreiben nicht wesentlicher Daten nach /var/cache/ oder ein Fehler beim
Erstellen einer angepassten Protokolldatei unter /var/log nicht dazu führt, dass die Anwendung nicht
läuft.
Das Verzeichnis /run/ ist seit der frühsten Systemstartphase verfügbar und kann immer beschrieben werden.
Es sollte für alle Laufzeitdaten und -Sockets verwandt werden, so dass Schreibzugriff auf z.B. /etc oder
/var nicht notwendig ist.
KNOTENTYPEN
Unix-Dateisysteme unterstützen verschiedene Arten von Dateiknoten, einschließlich regulärer Dateien,
Verzeichnisse, Symlinks, Zeichen- und Blockgeräteknoten, Sockets und FIFOs.
Es wird nachdrücklich empfohlen, dass /dev/ der einzige Ort ist, unterhalb dessen Geräteknoten abgelegt
werden. Ähnlich sollte /run/ der einzige Ort sein, an dem Sockets und FIFOs abgelegt werden. Reguläre
Dateien, Verzeichnisse und Symlinks können in allen Verzeichnissen verwandt werden.
SYSTEMPAKETE
Entwickler von Systempaketen sollten strengen Regeln beim Ablegen eigener Dateien im Dateisystem folgen.
Die nachfolgende Tabelle führt empfohlene Orte für bestimmte, vom Lieferanten bereitgestellte Dateien
auf.
Tabelle 1. Ort für Lieferantendateien aus Systempaketen
┌────────────────────────────────────┬───────────────────────────────────────┐
│ Verzeichnis │ Zweck │
├────────────────────────────────────┼───────────────────────────────────────┤
│ /usr/bin/ │ Paketprogramme, die im ausführbaren │
│ │ Suchpfad $PATH auftauchen sollen, für │
│ │ eine der unterstützten Architekturen, │
│ │ die zum Betriebssystem kompatibel │
│ │ ist, kompiliert. Es wird nicht │
│ │ empfohlen, interne Programme oder │
│ │ Programme, die typischerweise nicht │
│ │ von der Shell aufgerufen werden, wie │
│ │ Daemon-Programme, hier abzulegen. Da │
│ │ dieses Verzeichnis mit den meisten │
│ │ anderen Paketen des Systems gemeinsam │
│ │ benutzt wird, sollte besondere │
│ │ Sorgfalt darauf verwandt werden, für │
│ │ hier abzulegende Dateien eindeutige │
│ │ Namen auszuwählen, die wahrscheinlich │
│ │ nicht in Konflikt zu den Dateien │
│ │ anderer Pakete stehen. │
├────────────────────────────────────┼───────────────────────────────────────┤
│ /usr/lib/Arch-Kennung/ │ Öffentliche dynamische Bibliotheken │
│ │ des Pakets. Wie oben sollten Sie │
│ │ sorgfältig bei der Verwendung zu │
│ │ generischer Namen sein und eindeutige │
│ │ Namen für Ihre hier abzulegenden │
│ │ Dateien wählen, um Namenskonflikte zu │
│ │ vermeiden. │
├────────────────────────────────────┼───────────────────────────────────────┤
│ /usr/lib/Paket/ │ Private statische │
│ │ Lieferantenressourcen des Pakets, │
│ │ einschließlich privater Programme und │
│ │ Bibliotheken oder jede andere Art von │
│ │ rein-lesbaren Lieferantendaten. │
├────────────────────────────────────┼───────────────────────────────────────┤
│ /usr/lib/Architekturkennung/Paket/ │ Private weitere Lieferantenressourcen │
│ │ des Pakets, die architekturabhängig │
│ │ sind und nicht von verschiedenen │
│ │ Architekturen gemeinsam benutzt │
│ │ werden können. Beachten Sie, dass │
│ │ dies im Allgemeinen keine privaten │
│ │ Programme einschließt, da Programme │
│ │ einer bestimmten Architektur frei von │
│ │ jeder anderen unterstützten │
│ │ Systemarchitektur aufgerufen werden │
│ │ können. │
├────────────────────────────────────┼───────────────────────────────────────┤
│ /usr/include/Paket/ │ Öffentliche C/C++-APIs von │
│ │ öffentlichen dynamischen Bibliotheken │
│ │ des Pakets. │
└────────────────────────────────────┴───────────────────────────────────────┘
Zusätzliche statische Lieferantendateien können in der Hierarchie /usr/share an die Orte, die durch
verschiedene, zutreffende Spezifikationen festgelegt werden, installiert werden.
Die folgenden Verzeichnisse müssen für durch das Paket für lokale Konfiguration und zur Laufzeit
erstellte Dateien verwandt werden:
Tabelle 2. Ort für variable Dateien aus Systempaketen
┌───────────────────┬───────────────────────────────────────┐
│ Verzeichnis │ Zweck │
├───────────────────┼───────────────────────────────────────┤
│ /etc/Paket/ │ Systemspezifische Konfiguration für │
│ │ das Paket. Es wird empfohlen, │
│ │ standardmäßig sichere │
│ │ Rückfalloptionen zu verwenden, falls │
│ │ diese Konfiguration fehlt, falls das │
│ │ möglich ist. Alternativ kann ein │
│ │ tmpfiles.d(5)-Fragment verwandt │
│ │ werden, um die notwendigen Dateien │
│ │ und Verzeichnisse von │
│ │ /usr/share/factory/ während des │
│ │ Systemstarts mittels der Anweisungen │
│ │ »L« oder »C« zu symlinken oder zu │
│ │ kopieren. │
├───────────────────┼───────────────────────────────────────┤
│ /run/Pakete/ │ Laufzeitdaten für das Paket. Pakete │
│ │ müssen in der Lage sein, die │
│ │ notwendigen Unterverzeichnisse in │
│ │ diesem Baum selbst zu erstellen, da │
│ │ das Verzeichnis beim Systemstart │
│ │ automatisch geleert wird. Alternativ │
│ │ kann ein tmpfiles.d(5)-Fragment │
│ │ verwandt werden, um die notwendigen │
│ │ Verzeichnisse während des │
│ │ Systemstarts zu erstellen oder die │
│ │ Anweisung RuntimeDirectory= von │
│ │ Dienste-Units kann verwandt werden, │
│ │ um sie beim Hochfahren des Dienstes │
│ │ zu erstellen (siehe systemd.unit(5) │
│ │ für Details). │
├───────────────────┼───────────────────────────────────────┤
│ /run/log/Paket/ │ Laufzeitprotokolldaten für das Paket. │
│ │ Wie oben muss das Paket │
│ │ sicherstellen, dieses Verzeichnis │
│ │ falls notwendig zu erstellen, da es │
│ │ bei jedem Systemstart bereinigt wird. │
├───────────────────┼───────────────────────────────────────┤
│ /var/cache/Paket/ │ Dauerhafte Zwischenspeicherdaten des │
│ │ Pakets. Falls dieses Verzeichnis │
│ │ geleert wird, sollte die Anwendung │
│ │ beim nächsten Aufruf korrekt │
│ │ arbeiten, allerdings möglicherweise │
│ │ verlangsamt, da sie alle lokalen │
│ │ Zwischenspeicherdateien neu aufbauen │
│ │ muss. Die Anwendung muss in der Lage │
│ │ sein, dieses Verzeichnis wieder zu │
│ │ erstellen, falls es fehlt und │
│ │ notwendig ist. Um ein leeres │
│ │ Verzeichnis zu erstellen, kann ein │
│ │ tmpfiles.d(5)-Fragment oder die │
│ │ Anweisung CacheDirectory= von │
│ │ Dienste-Units (siehe systemd.unit(5)) │
│ │ verwandt werden. │
├───────────────────┼───────────────────────────────────────┤
│ /var/lib/Paket/ │ Dauerhafte private Daten des Pakets. │
│ │ Dies ist der Hauptort, um dauerhafte │
│ │ Daten abzulegen, die nicht in die │
│ │ anderen aufgeführten Kategorien │
│ │ fallen. Pakete sollten in der Lage │
│ │ sein, die notwendigen │
│ │ Unterverzeichnisse in diesem Baum │
│ │ selbst zu erstellen, da das │
│ │ Verzeichnis beim Systemstart fehlen │
│ │ könnte. Um ein leeres Verzeichnis zu │
│ │ erstellen, kann ein │
│ │ tmpfiles.d(5)-Fragment oder die │
│ │ Anweisung CacheDirectory= von │
│ │ Dienste-Units (siehe systemd.unit(5)) │
│ │ verwandt werden. │
├───────────────────┼───────────────────────────────────────┤
│ /var/log/Paket/ │ Dauerhafte Protokolldaten des Pakets. │
│ │ Wie oben sollte das Paket │
│ │ sicherstellen, das Verzeichnis, falls │
│ │ notwendig, möglicherweise mittels │
│ │ tmpfiles.d(5) oder LogsDirectory= │
│ │ (siehe systemd.exec(5)) zu erstellen, │
│ │ da es fehlen könnte. │
├───────────────────┼───────────────────────────────────────┤
│ /var/spool/Paket/ │ Dauerhafte Spool-/Warteschlangendaten │
│ │ des Pakets. Wie oben sollte das Paket │
│ │ sicherstellen, das Verzeichnis, falls │
│ │ notwendig, zu erstellen, da es fehlen │
│ │ könnte. │
└───────────────────┴───────────────────────────────────────┘
BENUTZERPAKETE
Programme, die im Benutzerkontext laufen, sollten strengen Regeln bei der Ablage ihrer eigenen Dateien im
Home-Verzeichnis des Benutzers folgen. Die nachfolgende Tabelle führt empfohlene Orte im Home-Verzeichnis
für bestimmte Arten von Dateien des Lieferanten auf, falls die Anwendung im Home-Verzeichnis installiert
ist. (Systemweit installierte Benutzeranwendungen sind von den oben dargestellten Regeln für
Lieferantendateien abgedeckt.)
Tabelle 3. Lieferantenpaketorte unter dem Home-Verzeichnis des Benutzers
┌────────────────────────────────────────┬───────────────────────────────────────┐
│ Verzeichnis │ Zweck │
├────────────────────────────────────────┼───────────────────────────────────────┤
│ ~/.local/bin/ │ Paketprogramme, die im ausführbaren │
│ │ Suchpfad $PATH auftauchen sollen. Es │
│ │ wird nicht empfohlen, interne │
│ │ Programme oder Programme, die │
│ │ typischerweise nicht von der Shell │
│ │ aufgerufen werden, wie │
│ │ Daemon-Programme, hier abzulegen. Da │
│ │ dieses Verzeichnis mit den meisten │
│ │ anderen Paketen des Systems gemeinsam │
│ │ benutzt wird, sollte besondere │
│ │ Sorgfalt darauf verwandt werden, für │
│ │ hier abzulegende Dateien eindeutige │
│ │ Namen auszuwählen, die wahrscheinlich │
│ │ nicht in Konflikt zu den Dateien │
│ │ anderer Pakete stehen. │
├────────────────────────────────────────┼───────────────────────────────────────┤
│ ~/.local/lib/Architekturkennung/ │ Öffentliche dynamische Bibliotheken │
│ │ des Pakets. Wie oben sollten Sie │
│ │ sorgfältig bei der Verwendung │
│ │ übermäßig generischer Namen sein und │
│ │ eindeutige Namen für Ihre hier │
│ │ abzulegenden Dateien wählen, um │
│ │ Namenskonflikte zu vermeiden. │
├────────────────────────────────────────┼───────────────────────────────────────┤
│ ~/.local/lib/Paket/ │ Private, statische │
│ │ Lieferantenressourcen des Pakets, │
│ │ kompatibel zu allen Architekturen │
│ │ oder jede Art von rein lesbaren │
│ │ Lieferantendaten. │
├────────────────────────────────────────┼───────────────────────────────────────┤
│ ~/.local/lib/Architekturkennung/Paket/ │ Private andere Lieferantenressourcen │
│ │ des Pakets, die architekturabhängig │
│ │ sind und nicht auf verschiedenen │
│ │ Architekturen gemeinsam benutzt │
│ │ werden können. │
└────────────────────────────────────────┴───────────────────────────────────────┘
Zusätzliche statische Lieferantendateien können in der Hierarchie ~/.local/share/ abgelegt werden und
dabei die im obigen Abschnitt »Vom Lieferanten bereitgestellte Betriebssystemressourcen« festgelegten
Verzeichnisse spiegeln.
Die folgenden Verzeichnisse müssen für durch das Paket für benutzerbezogene lokale Konfiguration und zur
Laufzeit erstellte Dateien verwandt werden:
Tabelle 4. Ort für variable Dateien aus Benutzerpaketen
┌─────────────────────────┬──────────────────────────────────────┐
│ Verzeichnis │ Zweck │
├─────────────────────────┼──────────────────────────────────────┤
│ ~/.config/Paket/ │ Benutzerbezogene Konfiguration und │
│ │ Zustand für das Paket. Es wird │
│ │ verlangt, sichere │
│ │ Rückfallstandardwerte zu verwenden, │
│ │ falls diese Konfiguration fehlt. │
├─────────────────────────┼──────────────────────────────────────┤
│ $XDG_RUNTIME_DIR/Paket/ │ Benutzerlaufzeitdaten für das Paket. │
├─────────────────────────┼──────────────────────────────────────┤
│ ~/.cache/Paket/ │ Dauerhafte Zwischenspeicherdaten des │
│ │ Pakets. Falls dieses Verzeichnis │
│ │ geleert wird, sollte die Anwendung │
│ │ beim nächsten Aufruf korrekt │
│ │ arbeiten, allerdings möglicherweise │
│ │ verlangsamt, da sie alle lokalen │
│ │ Zwischenspeicherdateien neu aufbauen │
│ │ muss. Die Anwendung muss in der Lage │
│ │ sein, dieses Verzeichnis wieder zu │
│ │ erstellen, falls es fehlt und │
│ │ notwendig ist. │
└─────────────────────────┴──────────────────────────────────────┘
SIEHE AUCH
systemd(1), hier(7), systemd-path(1), systemd-gpt-auto-generator(8), sysctl.d(5), tmpfiles.d(5),
pkg-config(1), systemd.unit(5)
ANMERKUNGEN
1. Dateisystem-Hierarchie
http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html
2. XDG-Basisverzeichnisspezifikation
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
3. XDG-Benutzerverzeichnisse
https://www.freedesktop.org/wiki/Software/xdg-user-dirs
4. IEEE Std 1003.1
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03
5. Sichere Verwendung von /tmp und /var/tmp
https://systemd.io/TEMPORARY_DIRECTORIES
6. Multiarch-Architekturkennungen (Tupel)
https://wiki.debian.org/Multiarch/Tuples
Ü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 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.
systemd 255 FILE-HIERARCHY(7)