Provided by: manpages-de-dev_2.15-1build1_all bug

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  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 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 Pfadname 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 Gruppenkennungen
              ausgeführt. In der Voreinstellung verwendet faccessat() die realen  Kennungen  (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 pathname 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
              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:  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  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  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  5.02  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>.