Ubuntu Manpage: access, faccessat, faccessat2 - prüft die Zugriffsrechte des Benutzers an einer Datei

BEZEICHNUNG

       access, faccessat, faccessat2 - prüft die Zugriffsrechte des Benutzers an einer Datei

ÜBERSICHT

       #include <unistd.h>

       int access(const char *Pfadname, int Modus);

       #include <fcntl.h>           /* Definition der AT_*-Konstanten */
       #include <unistd.h>

       int faccessat(int Verzdd, const char *Pfadname, int Modus, int Schalter);
                       /* Siehe aber auch C-Bibliothek/Kernel-Unterschiede, unten */

       int faccessat2(int Verzdd, const char *Pfadname, int Modus, int Schalter);

   Mit Glibc erforderliche Makros (siehe feature_test_macros(7)):

       faccessat():
           Seit Glibc 2.10:
               _POSIX_C_SOURCE >= 200809L
           Vor Glibc 2.10:
               _ATFILE_SOURCE

BESCHREIBUNG

access() prüft, ob der Prozess auf die Datei Pfadname zugreifen kann. Falls Pfadname ein
symbolischer Link ist, werden die Zugriffsrechte der referenzierten Datei geprüft.

Modus gibt an, welche Zugriffsprüfungen durchgeführt werden sollen. Das ist entweder der
Wert F_OK oder eine Bitmaske, die aus einem der Werte R_OK, W_OK, X_OK und F_OK besteht
(oder dem bitweisen ODER mehrerer dieser Werte). F_OK überprüft, ob die Datei existiert.
R_OK, W_OK und X_OK überprüfen, ob die Datei existiert und entsprechend Lese-, Schreib-
und Ausführungsrechte gewährt.

Diese Prüfung wird mit der realen UID und der realen GID des Prozesses durchgeführt und
nicht mit den effektiven Kennungen, wie das beim tatsächlichen Versuch, eine Operation
auszuführen, der Fall ist (z.B. mit open(2) auf eine Datei zugreifen). Ähnlich verwendet
die Prüfung für den Benutzer »root« die Menge der erlaubten Capabilities statt die Menge
der effektiven Capabilities und für nicht-root-Benutzer verwendet die Prüfung die leere
Menge an Capabilities.

Dadurch können »set-UID«-Programme und Programme, die mit Capabilities ausgestattet sind,
leicht die Berechtigungen des Aufrufenden feststellen. Mit anderen Worten, access()
beantwortet nicht die Frage: »Kann ich diese Datei lesen/schreiben/ausführen?«. Es
beantwortet eine etwas andere Frage: »Unter der Annahme, dass ich ein ›setuid‹-Programm
bin: Kann der Benutzer, der mich aufrief, diese Datei lesen/schreiben/ausführen?«. Dies
ermöglicht »set-user-ID«-Programmen, bösartige Benutzer davon abzuhalten, Dateien zu
lesen, die sie nicht lesen können sollten.

Falls der aufrufende Prozess privilegiert ist (d. h., seine reale UID ist null), wird eine
X_OK-Prüfung für eine reguläre Datei erfolgreich sein, wenn Ausführungsrechte für
Eigentümer, Gruppe oder Andere gegeben sind.

faccessat()
faccessat() funktioniert genauso wie access(), außer mit den hier beschriebenen
Unterschieden.

Falls der in Pfadname übergebene Pfadname relativ ist, wird er als relativ zu dem vom
Dateideskriptor Verzdd referenzierten Verzeichnis interpretiert (statt relativ zum
aktuellen Arbeitsverzeichnis des aufrufenden Prozesses, wie es bei access() für einen
relativen Pfadnamen erfolgt).

Falls Pfadname relativ ist und Verzdd den speziellen Wert AT_FDCWD annimmt, wird Pfadname
als relativ zum aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie
access()).

Falls Pfadname absolut ist, wird Verzdd ignoriert.

Schalter wird durch bitweises ODER aus null oder mehr der folgenden Werte konstruiert:

AT_EACCESS
Eine Zugriffsprüfung wird mittels der effektiven Benutzer- und Gruppenkennungen
ausgeführt. In der Voreinstellung verwendet faccessat() die realen Kennungen (wie
access()).

AT_SYMLINK_NOFOLLOW
Falls Pfadname ein symbolischer Link ist, wird er nicht dereferenziert: stattdessen
wird eine Information zum Link selbst zurückgegeben.

Lesen Sie openat(2) für eine Beschreibung der Notwendigkeit von faccessat().

faccessat2()
Die oben dargestellte Beschreibung von faccessat() entspricht POSIX.1 und der von Glibc
bereitgestellten Implementierung. Allerdings war die Glibc-Implementierung eine nicht
perfekte Nachbildung (siehe FEHLER), die die Tatsache kaschierte, dass der rohe
Linux-Systemaufruf faccessat() über kein Argument Schalter verfügt. Um eine korrekte
Implementierung zu erlauben, fügte Linux 5.8 den Systemaufruf faccessat2() hinzu, der das
Argument Schalter unterstützt und eine korrekte Implementierung der Wrapper-Funktion
faccessat() erlaubt.

RÜCKGABEWERT

       Bei Erfolg (alle abgefragten Zugriffsrechte sind gegeben oder Modus ist F_OK und die Datei
       existiert)  wird Null zurückgegeben. Bei einem Fehler (mindestens eine in Modus abgefragte
       Zugriffsart fehlt oder Modus ist F_OK und die  Datei  existiert  nicht  oder  ein  anderer
       Fehler trat auf) wird -1 zurückgegeben und errno entsprechend gesetzt.

FEHLER

access() und faccessat() schlagen fehl, falls:

EACCES Die abgefragte Zugriffsart auf die Datei würde verwehrt oder das Suchen wird in
einem der Verzeichnisse des Pfadpräfixes von Pfadname verweigert (siehe auch
path_resolution(7)).

ELOOP Bei der Auflösung von Pfadname wurden zu viele symbolische Links gefunden.

ENAMETOOLONG
Pfadname ist zu lang.

ENOENT Eine Komponente von Pfadname existiert nicht oder ist ein toter symbolischer Link.

ENOTDIR
Eine als Verzeichnis benutzte Komponente von Pfadname ist kein Verzeichnis.

EROFS Es wurde Schreibberechtigung für eine Datei auf einem nur lesbaren Dateisystem
abgefragt.

access() und faccessat() können fehlschlagen, falls:

EFAULT Pfadname zeigt aus dem für Sie zugänglichen Adressraum heraus.

EINVAL Modus wurde falsch angegeben.

EIO Es ist ein E/A-Fehler (engl. I/O) aufgetreten.

ENOMEM Es war nicht genügend Kernelspeicher verfügbar.

ETXTBSY
Es wurde Schreibzugriff für ein ausführbares Programm abgefragt, das gerade
ausgeführt wird.

Die folgenden Fehler können bei faccessat() zusätzlich auftreten:

EBADF Verzdd ist kein zulässiger Dateideskriptor.

EINVAL Unzulässiger Schalter in Schalter angegeben.

ENOTDIR
Pfadname ist relativ und Verzdd ist ein Dateideskriptor, der sich auf eine Datei
bezieht, die kein Verzeichnis ist.

VERSIONEN

       faccessat() wurde zu Linux in Kernel 2.6.16 hinzugefügt; Bibliotheksunterstützung wurde in
       Glibc in Version 2.4 hinzugefügt.

       faccessat2() wurde zu Linux in Version 5.8 hinzugefügt.

KONFORM ZU

       access(): SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.

       faccessat(): POSIX.1-2008.

       faccessat2(): Linux-spezifisch.

ANMERKUNGEN

Warnung: Werden diese Aufrufe dazu verwandt, mittels open(2) zu prüfen, ob einem Benutzer
beispielsweise erlaubt ist, eine Datei zu öffnen, bevor dies tatsächlich erfolgt, führt
dies zu einem Sicherheitsloch. Der Benutzer könnte diesen kurzen Zeitraum zwischen der
Überprüfung und dem Öffnen der Datei benutzen, um sie zu verändern. Darum sollte die
Verwendung dieses Systemaufrufs vermieden werden. (Im gerade beschriebenen Beispiel wäre
eine sicherere Alternative, vorübergehend die effektive Benutzerkennung des Prozesses auf
die reale Benutzerkennung zu setzen und dann open(2) aufzurufen.)

access() löst immer symbolische Links auf. Wenn Sie Rechte eines symbolischen Links prüfen
müssen, verwenden Sie faccessat() mit dem Schalter AT_SYMLINK_NOFOLLOW.

Diese Aufrufe geben einen Fehler zurück, wenn irgendeine der Zugriffsarten in Modus
verwehrt wird, sogar wenn einige der anderen Zugriffsarten in Modus gestattet sind.

Falls der aufrufende Prozess über entsprechende Privilegien verfügt (d. h. Superuser ist),
gestattet POSIX.1-2001 einer Implementierung, für eine X_OK-Prüfung Erfolg zu melden, auch
wenn keines der Datei-Ausführungsbits gesetzt ist. Linux tut das nicht.

Auf eine Datei kann nur zugegriffen werden, wenn jedes der Verzeichnisse im Pfadpräfix von
Pfadname suchenden (d. h. ausführenden) Zugriff zulässt. Wenn auf irgendein Verzeichnis
nicht zugegriffen werden kann, schlägt unabhängig von den Zugriffsrechten für die Datei
selbst der Aufruf von access() fehl.

Nur die Zugriffs-Bits werden geprüft, nicht der Dateityp oder -inhalt. Deshalb bedeutet
ein als beschreibbar erkanntes Verzeichnis wahrscheinlich, dass in ihm Dateien erstellt
werden können und nicht, dass das Verzeichnis als Datei geschrieben werden kann. Ebenso
kann eine DOS-Datei als »ausführbar« diagnostiziert werden, aber ein Aufruf von execve(2)
kann immer noch fehlschlagen.

Diese Aufrufe arbeiten wahrscheinlich nicht korrekt mit NFS-Dateisystemen, für die
UID-Mapping aktiviert ist, weil das UID-Mapping auf dem Server erfolgt und dem Client, der
die Berechtigungen prüft, verborgen bleibt (NFS-Versionen ab 3 führen die Überprüfung auf
dem Server aus). Ähnliche Probleme können mit FUSE-Einhängungen auftreten.

Unterschiede C-Bibliothek/Kernel
Der reine faccessat()-Systemaufruf akzeptiert nur die ersten drei Argumente. Die Schalter
AT_EACCESS und AT_SYMLINK_NOFOLLOW sind eigentlich in der Glibc-Wrapper-Funktion für
faccessat() implementiert. Falls einer dieser Schalter angegeben ist, dann nutzt die
Wrapper-Funktion fstatat(2), um die Zugriffsrechte zu ermitteln; siehe aber auch FEHLER.

Anmerkungen zur Glibc
Wenn in älteren Kerneln faccessat() nicht verfügbar sind und die Schalter AT_EACCESS und
AT_SYMLINK_NOFOLLOW nicht angegeben sind, dann weicht die Glibc-Wrapper-Funktion auf
access() aus. Wenn Pfadname ein relativer Pfadname ist, konstruiert die Glibc einen
Pfadnamen, der auf dem symbolischen Link in /proc/self/fd basiert, der dem Verzdd-Argument
entspricht.

FEHLER

       Da der Linux-Kernel-Systemaufruf faccessat()  das  Argument  Schalter  nicht  unterstützt,
       stellte  die  Glibc-Wrapperfunktion  faccessat()  in  Glibc 2.32 und älter eine Nachahmung
       bereit,  die  ACLs  nicht  berücksichtigt.  Beginnend  mit  Glibc  2.33,   vermeidet   die
       Wrapper-Funktion  diesen Fehler, indem sie den Systemaufruf faccessat2() verwendet, sofern
       er vom zugrundeliegenden Kernel unterstützt wird.

       Im Kernel 2.4 (und früher) ist das Verhalten bei der  Handhabung  von  X_OK-Prüfungen  für
       Superuser etwas seltsam. Falls alle Kategorien der Ausführungsberechtigung für eine Datei,
       die kein Verzeichnis ist, deaktiviert sind, gibt nur die Zugriffsprüfung  -1  zurück,  für
       die  Modus  lediglich als X_OK angegeben ist; falls auch R_OK oder W_OK in Modus angegeben
       ist, gibt access() für solche Dateien  0  zurück.  Frühe  2.6-Kernel  (bis  einschließlich
       2.6.3) verhielten sich in der gleichen Weise wie 2.4-Kernel.

       In  Kerneln  vor 2.6.20 ignorierten diese Aufrufe den Effekt des Schalters MS_NOEXEC, wenn
       dieser für das Einhängen (den Aufruf von mount(2)) für das zugrunde  liegende  Dateisystem
       verwendet wurde. Seit Kernel 2.6.20 wird der Schalter MS_NOEXEC beachtet.

SIEHE AUCH

       chmod(2), chown(2), open(2), setgid(2), setuid(2), stat(2), euidaccess(3), credentials(7),
       path_resolution(7), symlink(7)

KOLOPHON

       Diese Seite  ist  Teil  der  Veröffentlichung  5.10  des  Projekts  Linux-man-pages.  Eine
       Beschreibung  des  Projekts,  Informationen,  wie  Fehler gemeldet werden können sowie die
       aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Elmar Jansen <ej@pumuckel.gun.de>,
       Martin  Schulze  <joey@infodrom.org>,  Martin  Eberhard Schauer <Martin.E.Schauer@gmx.de>,
       Mario Blättermann <mario.blaettermann@gmail.com>, Helge Kreutzmann  <debian@helgefjell.de>
       und Dr. Tobias Quathamer <toddy@debian.org> 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⟩.