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

BEZEICHNUNG

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

ÜBERSICHT

       #include <unistd.h>

       int access(const char *pathname, int mode);

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

       int faccessat(int dirfd, const char *pathname, int mode, int flags);

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

       faccessat():
           Seit Glibc 2.10:
               _XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L
           Bis Glibc 2.10:
               _ATFILE_SOURCE

BESCHREIBUNG

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

mode legt fest, 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.

The check is done using the calling process's real UID and GID, rather than the effective
IDs as is done when actually attempting an operation (e.g., open(2)) on the file.
Similarly, for the root user, the check uses the set of permitted capabilities rather than
the set of effective capabilities; and for non-root users, the check uses an empty set of
capabilities.

This allows set-user-ID programs and capability-endowed programs to easily determine the
invoking user's authority. In other words, access() does not answer the "can I
read/write/execute this file?" question. It answers a slightly different question:
"(assuming I'm a setuid binary) can the user who invoked me read/write/execute this
file?", which gives set-user-ID programs the possibility to prevent malicious users from
causing them to read files which users shouldn't be able to read.

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()
Der Systemaufruf faccessat() funktioniert genauso wie access(), außer mit den hier
beschriebenen Unterschieden.

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

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

Falls pathname absolut ist wird dirfd ignoriert.

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

AT_EACCESS
Eine Zugriffsprüfung wird mittels der effektiven Benutzer- und Gruppen-IDs
ausgeführt. In der Voreinstellung verwendet faccessat() die realen IDs (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().

RÜCKGABEWERT

       Bei Erfolg (alle abgefragten Zugriffsrechte sind gegeben oder mode ist F_OK und die  Datei
       existiert)  wird  Null zurückgegeben. Bei einem Fehler (mindestens eine in mode abgefragte
       Zugriffsart fehlt oder mode 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 in einer
der Dateien des Pfad-Präfixes wurde verwehrt (siehe auch path_resolution(7)).

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

ENAMETOOLONG
pathname ist zu lang.

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

ENOTDIR
Eine als Verzeichnis benutzte Komponente von pathname 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 pathname zeigt aus dem für Sie zugänglichen Adressraum heraus.

EINVAL mode wurde falsch angegeben.

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

ENOMEM Es war nicht genügend Kernel-Speicher 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 dirfd ist kein zulässiger Dateideskriptor.

EINVAL Unzulässiger Schalter wurde in flags angegeben.

ENOTDIR
Pfadname ist relativ und dirfd 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.

KONFORM ZU

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

       faccessat(): POSIX.1-2008.

ANMERKUNGEN

Warnung: Beispielsweise öffnet die Überprüfung mittels access(), ob ein Benutzer eine
Datei öffnen darf, bevor das tatsächlich mittels open(2) versucht wird, eine
Sicherheitslücke, da der Benutzer das kurze Zeitintervall zwischen der Überprüfung und dem
Öffnen der Datei aus nutzen könnte, um die Datei zu manipulieren. Darum sollte die
Verwendung dieses Systemaufrufs vermieden werden. (Im gerade beschriebenen Beispiel wäre
eine sichere Alternative, vorübergehend die effektive Benutzer-ID des Prozesses auf die
reale Benutzer-ID zu setzen und danach open(2) aufzurufen.)

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

Diese Aufrufe geben einen Fehler zurück, wenn irgendeine der Zugriffsarten in mode
verwehrt wird, sogar wenn einige der anderen Zugriffsarten in mode 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 Pfad-Präfix
von pathname suchenden (d. h. ausführenden) Zugriff zullässt. Wenn auf irgendein
Verzeichnis nicht zugegriffen werden kann, wird unabhängig von den Zugriffsrechten für die
Datei selbst der Aufruf von access() fehlschlagen.

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, um die Zugriffsrechte zu ermitteln.

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 dirfd-Argument
entspricht.

FEHLER

       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  deaktiviert
       sind für eine Datei, die kein Verzeichnis ist, gibt nur die Zugriffsprüfung -1 zurück, für
       die mode lediglich als X_OK angegeben ist; falls auch R_OK oder  W_OK  in  mode  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  4.04  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 http://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>  und
       Mario Blättermann <mario.blaettermann@gmail.com> 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 <debian-l10n-german@lists.debian.org>.