.\" -*- coding: UTF-8 -*- .\" Copyright (C) 2003 Andries Brouwer (aeb@cwi.nl) .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH path_resolution 7 "2. Mai 2024" "Linux man\-pages 6.8" .SH BEZEICHNUNG path_resolution \- Wie ein Pfadname zu einer Datei aufgelöst wird .SH BESCHREIBUNG Einige UNIX/Linux\-Systemaufrufe haben als Parameter einen oder mehrere Dateinamen. Ein Dateiname (oder Pfadname) wird wie folgt aufgelöst: .SS "Schritt 1: Start des Auflösungsprozesses" Falls der Pfadname mit dem Zeichen »/« beginnt, wird das Wurzelverzeichnis des aufrufenden Prozesses als Startverzeichnis beim Nachschlagen verwandt. Ein Prozess erbt sein Wurzelverzeichnis von seinem Elternprozess. Normalerweise wird dies das Wurzelverzeichnis der Dateihierarchie sein. Durch die Verwendung des Systemaufrufs \fBchroot\fP(2) kann ein Prozess ein anderes Wurzelverzeichnis erhalten oder er kann mittels \fBopenat2\fP(2) mit dem gesetzten Schalter \fBRESOLVE_IN_ROOT\fP temporär ein anderes Wurzelverzeichnis erhalten. .P Ein Prozess kann einen komplett privaten Einhängenamensraum erhalten, falls er\[en]oder einer seiner Vorgänger\[en]durch einen Systemaufruf von \fBclone\fP(2) mit gesetztem Schalter \fBCLONE_NEWNS\fP gestartet wurde. Dieser handhabt den »/«\-Anteil des Pfadnamens. .P Falls der Pfadname nicht mit dem Zeichen »/« beginnt, ist das Nachschlage\-Startverzeichnis für den Pfadauflösungsprozess das aktuelle Arbeitsverzeichnis des Prozesses \[en] oder im Falle von Systemaufrufen im Stil von \fBopenat\fP(2), das Argument \fIdfd\fP (oder das aktuelle Arbeitsverzeichnis, falls \fBAT_FDCWD\fP als Argument \fIdfd\fP übergeben wurde). Das aktuelle Arbeitsverzeicnis wird vom Elternprozess geerbt und kann mittels des Systemaufrufs \fBchdir\fP(2) geändert werden. .P Pfadnamen, die mit dem Zeichen »/« beginnen, werden absolute Pfadnamen genannt. Alle anderen Pfadnamen heißen relative Pfadnamen. .SS "Schritt 2: Ablaufen entlang des Pfades" Das aktuelle Nachschlageverzeichnis wird auf das Nachschlage\-Startverzeichnis gesetzt. Jetzt wird für jede nicht abschließende Komponente des Pfadnamens diese im aktuellen Nachschlageverzeichnis nachgeschlagen. Hierbei ist eine Komponente eine Teilzeichenkette, die durch das Zeichen »/« abgetrennt wird. .P Falls der Prozess über keine Suchberechtigungen im aktuellen Nachschlage\-Verzeichnis verfügt, wird der Fehler \fBEACCES\fP (»Keine Berechtigung«) zurückgeliefert. .P Falls die Komponente nicht gefunden wird, wird der Fehler \fBENOENT\fP (»Datei oder Verzeichnis nicht gefunden«) zurückgeliefert. .P Falls eine Komponente gefunden wird, aber weder ein Verzeichnis noch ein symbolischer Link ist, wird der Fehler \fBENOTDIR\fP (»Ist kein Verzeichnis«) zurückgeliefert. .P Falls die Komponente gefunden wird und ein Verzeichnis ist, wird das aktuelle Nachschlage\-Verzeichnis auf dieses Verzeichnis gesetzt und zur nächsten Komponenten gewechselt. .P Falls die Komponente gefunden wird und ein symbolischer Link ist, wird zuerst dieser symbolische Link aufgelöst (mit dem anfänglichen Nachschlage\-Verzeichnis). Im Fehlerfall wird dieser Fehler zurückgeliefert. Falls das Ergebnis kein Verzeichnis ist, wird der Fehler \fBENOTDIR\fP zurückgeliefert. Falls die Auflösung des symbolischen Links erfolgreich ist und ein Verzeichnis zurückliefert, wird das aktuelle Nachschlage\-Verzeichnis auf dieses Verzeichnis gesetzt und zur nächsten Komponente gewechselt. Bachten Sie, dass dieser Auflösungsprozess Rekursionen enthalten kann, falls die Präfixkomponente (»dirname«) eines Pfadnamens einen Dateinamen enthält, der ein symbolischer Link ist, der sich auf ein Verzeichnis auflöst (wobei die Präfixkomponente dieses Verzeichnisses einen symbolischen Link enthalten könnte und so weiter). Um den Kernel gegen eine Stapelüberlauf und auch eine Diensteverweigerung zu schützen, gibt es Begrenzungen zur Rekursionstiefe und der maximalen Anzahl an gefolgten symbolischen Links. Ein Fehler \fBELOOP\fP wird zurückgeliefert, wenn das Maximum überschritten wurde (»Zu viele Ebenen aus symbolischen Links«). .P .\" .\" presently: max recursion depth during symlink resolution: 5 .\" max total number of symbolic links followed: 40 .\" _POSIX_SYMLOOP_MAX is 8 .\" MAXSYMLINKS is 40 .\" MAX_NESTED_LINKS .\" commit 894bc8c4662ba9daceafe943a5ba0dd407da5cd3 Derzeit ist in Linux die maximale Anzahl von beim Auflösen von Pfadnamen gefolgten symbolischen Links auf 40 begrenzt. In Linux vor 2.6.18 war die Begrenzung der Rekursionstiefe 5. Seit Linux 2.6.18 wurde diese Begrenzung auf 8 erhöht. In Linux 4.2 wurde der Code für die Pfadnamenauflösung überarbeitet, um die Verwendung von Rekursion zu beseitigen, so dass die einzige verbliebene Begrenzung die maximalen 40 Auflösungen für den gesamten Pfadnamen ist. .P Die Auflösung symbolischer Links während dieser Stufe kann mittels \fBopenat2\fP(2) durch den gesetzten Schalter \fBRESOLVE_NO_SYMLINKS\fP verhindert werden. .SS "Schritt 3: Finden des finalen Eintrags" Das Nachschlagen der finalen Komponente des Pfadnamens erfolgt genau wie der von allen anderen Komponenten, wie im vorherigen Schritt beschrieben, mit zwei Unterschieden: (i) die finale Komponente muss kein Verzeichnis sein (zumindest soweit, wie der Pfadauflösungsprozess betroffen ist \[en] es mag ein Verzeichnis oder keines sein müssen, abhängig von den Anforderungen des spezifischen Systemaufrufs) und (ii) es ist nicht unbedingt ein Fehler, falls die Komponente nicht gefunden wird \[en] vielleicht wird sie gerade erstellt. Die Details der Behandlung des abschließenden Eintrags werden in den Handbuchseiten der jeweiligen Systemaufrufe beschrieben. .SS "\&. und .." Herkömmlicherweise hat jedes Verzeichnis zwei Einträge (».« und »..«), die sich auf das Verzeichnis selbst bzw. sein übergeordnetes Verzeichnis beziehen. .P Der Pfadauflösungsprozess wird annehmen, dass diese zwei Einträge ihre konventionelle Bedeutung haben, unabhängig davon, ob sie im physischen Dateisystem tatsächlich vorhanden sind. .P Sie können nicht höher als die Wurzel aufsteigen: »/..« ist zu »/« identisch. .SS Einhängepunkte Nach einem Befehl \fImount Gerät Pfad\fP bezieht sich der Pfadname »Pfad« auf die Wurzel der Dateisystemhierarchie auf dem Gerät »Gerät« und nicht auf etwas, worauf es sich vorher bezog. .P Sie können sich außerhalb des eingehängten Dateisystems bewegen: »Pfad/..« bezieht sich auf das übergeordnete Verzeichnis von »Pfad« außerhalb der Dateisystemhierarchie von »Gerät«. .P Durchlauf von Einhängepunkten kann mittels \fBopenat2\fP(2) mit dem gesetzten Schalter \fBRESOLVE_NO_XDEV\fP verhindert werden (beachten Sie allerdings, dass dies auch den Durchlauf von Bind\-Einhängungen beschränkt). .SS "Abschließende Schrägstriche" Falls ein Pfadname mit einem »/« endet, der die Auflösung der vorherigen Komponente gemäß Schritt 2 erzwingt: die Komponente vor dem Schrägstrich existiert entweder und wird zu einem Verzeichnis aufgelöst oder sie benennt ein Verzeichnis, das sofort nach der Auflösung des Pfadnamens erstellt werden soll. Andernfalls wird ein abschließender »/« ignoriert. .SS "Finaler symbolischer Link" Falls die letzte Komponente des Pfadnamens ein symbolischer Link ist, hängt es vom Systemaufruf ab, ob die Datei, auf die referenziert wird, ein symbolischer Link ist oder das Ergebnis der Pfadauflösung seiner Inhalte. Beispielsweise wird der Systemaufruf \fBlstat\fP(2) auf einem symbolischen Link agieren, während \fBstat\fP(2) auf der Datei agiert, auf die der symbolische Link zeigt. .SS Längenbeschränkung Es gibt eine maximale Länge für Pfadnamen. Falls der Pfadname (oder ein Zwischenpfadname, der beim Auflösen von symbolischen Links erhalten wurde) zu lang ist, wird ein Fehler \fBENAMETOOLONG\fP zurückgeliefert (»Der Dateiname ist zu lang«). .SS "Leere Pfadnamen" Im ursprünglichen UNIX bezogen sich leere Pfadnamen auf das aktuelle Verzeichnis. Heutzutage beschließt POSIX, dass ein leerer Pfadname nicht erfolgreich aufgelöst werden darf. Linux liefert in diesem Fall \fBENOENT\fP zurück. .SS Berechtigungen Die Berechtigungsbits einer Datei bestehen aus drei Gruppen von drei Bits: siehe \fBchmod\fP(1) und \fBstat\fP(2). Die erste Gruppe der drei wird verwandt, wenn die effektive Benutzerkennung des aufrufenden Prozesses identisch zu der Eigentümerkennung der Datei ist. Die zweite Gruppe der drei wird verwandt, wenn die Gruppenkennung der Datei entweder mit der effektiven Gruppenkennung des aufrufenden Prozesses übereinstimmt oder eine der ergänzenden Gruppenkennungen des aufrufenden Prozesses ist (wie durch \fBsetgroups\fP(2) gesetzt). Falls nichts davon zutrifft, wird die dritte Gruppe verwandt. .P Von den drei verwandten Bits bestimmt das erste Bit die Leseberechtigung, das zweite die Schreibberechtigung und das letzte die Ausführberechtigung im Falle von gewöhnlichen Dateien oder die Suchberechtigung im Falle von Verzeichnissen. .P Linux verwendet fsuid anstelle der effektiven Benutzerkennung bei Berechtigungsprüfungen. Normalerweise ist die fsuid identisch mit der effektiven Benutzerkennung, aber die fsuid kann mit dem Systemaufruf \fBsetfsuid\fP(2) geändert werden. .P (Hier steht »fsuid« für etwas wie »Dateisystembenutzerkennung«. Das Konzept wurde für die Implementierung von NFS\-Servern im Benutzerbereich zu einem Zeitpunkt benötigt, zu dem ein Prozess ein Signal zu einem anderen Prozess mit der gleichen effektiven Benutzerkennung senden konnte. Dies ist jetzt veraltet. Niemand sollte \fBsetfsuid\fP(2) verwenden.) .P .\" FIXME . say something about filesystem mounted read-only ? Auf ähnliche Weise verwendet Linux die fsgid (»Dateisystemgruppenkennung«) anstelle der effektiven Gruppenkennung. Siehe \fBsetfsgid\fP(2). .SS "Umgehen von Berechtigungsprüfungen: Superuser und Capabilitys" .\" (but for exec at least one x bit must be set) -- AEB .\" but there is variation across systems on this point: for .\" example, HP-UX and Tru64 are as described by AEB. However, .\" on some implementations (e.g., Solaris, FreeBSD), .\" access(X_OK) by superuser will report success, regardless .\" of the file's execute permission bits. -- MTK (Oct 05) Auf einem traditionellen UNIX\-System ist der Superuser (\fIroot\fP, Benutzerkennung 0) allmächtig und umgeht alle Berechtigungseinschränkungen beim Zugriff auf Dateien. .P Unter Linux sind die Superuser\-Privilegien in Capabilitys aufgeteilt (siehe \fBcapabilities\fP(7)). Zwei Capabilitys sind für Dateiberechtigungsüberprüfungen relevant: \fBCAP_DAC_OVERRIDE\fP und \fBCAP_DAC_READ_SEARCH\fP. (Ein Prozess hat diese Capabilitys, falls seine fsuid 0 ist.) .P Die Capability \fBCAP_DAC_OVERRIDE\fP setzt alle Berechtigungsprüfungen außer Kraft, aber gewährt die Ausführberechtigung nur, falls mindestens eines der drei Ausführ\-Berechtigungs\-Bits der Datei gesetzt ist. .P .\" FIXME . say something about immutable files .\" FIXME . say something about ACLs Die Capability \fBCAP_DAC_READ_SEARCH\fP gewährt Lese\- und Suchberechtigungen für Verzeichnisse und Leseberechtigungen für gewöhnliche Dateien. .SH "SIEHE AUCH" \fBreadlink\fP(2), \fBcapabilities\fP(7), \fBcredentials\fP(7), \fBsymlink\fP(7) .PP .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. .PP Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. .PP Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die .MT debian-l10n-german@lists.debian.org Mailingliste der Übersetzer .ME .