Provided by: manpages-de-dev_1.4-1_all bug

BEZEICHNUNG
       access - prüft die Zugriffsrechte des realen Benutzers an einer Datei


ÜBERSICHT
       #include <unistd.h>

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


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).  Dadurch  können
       »set-UID«-Programme die Berechtigungen des Aufrufenden feststellen.

       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.


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() schlägt 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() kann 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.


KONFORM ZU
       SVr4, 4.3BSD, POSIX.1-2001.


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 UID des Prozesses auf die reale UID 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.

       access() gibt 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.

       access() arbeitet 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.


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 ignorierte access() 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 beachtet access() diesen Schalter.


SIEHE AUCH
       chmod(2), chown(2), faccessat(2), open(2), setgid(2), setuid(2),  stat(2),  euidaccess(3),
       credentials(7), path_resolution(7)


KOLOPHON
       This  page  is  part  of release 3.54 of the Linux man-pages project. A description of the
       project,    and    information    about    reporting    bugs,    can    be    found     at
       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>.