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

bezeichnung
übersicht
beschreibung
rückgabewert
fehler
versionen
konform zu
anmerkungen
fehler
siehe auch
kolophon
übersetzung

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:
               _POSIX_C_SOURCE >= 200809L
           Vor 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.

Diese Prüfung wird mit der realen UID und der realen GID des Prozesses durchgeführt und nicht mit den
effektiven IDs, 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 leicht 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 Benutzern 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()
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 pathname 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 wird in einer der
Verzeichnisse des Pfadpräfixes von pathname verweigert (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 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 dirfd ist kein zulässiger Dateideskriptor.

EINVAL Unzulässiger Schalter in flags angegeben.

ENOTDIR
pathname 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: Werden diese Aufrufe dazu verwandt, mittels open(2) zu prüfen, ob einem Benutzer beispielsweise
erlaubt ist, eine Datei zu öffen, bevor dies tatsächlich erfolgt, führt 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 Benutzer-ID des Prozesses auf die
reale Benutzer-ID 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 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 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, 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
pathname 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 für eine  Datei,  die  kein  Verzeichnis  ist,
       deaktiviert  sind, 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.15  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 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>.