table of contents
- BEZEICHNUNG
- BESCHREIBUNG
- ALLGEMEINE STRUKTUR
- LAUFZEITDATEN
- VOM LIEFERANTEN BEREITGESTELLTE BETRIEBSSYSTEMRESSOURCEN
- DAUERHAFTE VARIABLE SYSTEMDATEN
- VIRTUELLE KERNEL- UND API-DATEISYSTEME
- KOMPATIBILITÄTS-SYMLINKS
- HOME-VERZEICHNIS
- SCHREIBZUGRIFF
- KNOTENTYPEN
- SYSTEMPAKETE
- BENUTZERPAKETE
- SIEHE AUCH
- ANMERKUNGEN
- ÜBERSETZUNG
- bookworm 4.18.1-1
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.24.0-2
FILE-HIERARCHY(7) | file-hierarchy | FILE-HIERARCHY(7) |
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¶
/
/boot/
/efi/
/etc/
/home/
/root/
/srv/
/tmp/
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].
LAUFZEITDATEN¶
/run/
/run/log/
/run/user/
VOM LIEFERANTEN BEREITGESTELLTE BETRIEBSSYSTEMRESSOURCEN¶
/usr/
/usr/bin/
/usr/include/
/usr/lib/
/lib/Arch-Kennung/
# systemd-path system-library-arch
/usr/share/
/usr/share/doc/
/usr/share/factory/etc/
/usr/share/factory/var/
DAUERHAFTE VARIABLE SYSTEMDATEN¶
/var/
/var/cache/
/var/lib/
/var/log/
/var/spool/
/var/tmp/
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].
VIRTUELLE KERNEL- UND API-DATEISYSTEME¶
/dev/
/dev/shm/
/proc/
/proc/sys/
/sys/
/sys/fs/cgroup/
KOMPATIBILITÄTS-SYMLINKS¶
/bin/, /sbin/, /usr/sbin/
/lib/
/lib64/
/var/run/
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/
~/.config/
~/.local/bin/
~/.local/lib/
~/.local/lib/Architekturkennung/
~/.local/share/
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. |
/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. |
/lib/Paket/ | Private statische Lieferantenressourcen des Pakets, einschließlich privater Programme und Bibliotheken oder jede andere Art von rein-lesbaren Lieferantendaten. |
/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.unit(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
- 2.
- XDG-Basisverzeichnisspezifikation
- 3.
- XDG-Benutzerverzeichnisse
- 4.
- IEEE Std 1003.1
- 5.
- Sichere Verwendung von /tmp und /var/tmp
- 6.
- Multiarch-Architekturkennungen (Tupel)
Ü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 251 |