Provided by: manpages-de-dev_4.23.1-1_all bug

BEZEICHNUNG

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

BIBLIOTHEK

       Standard-C-Bibliothek (libc, -lc)

Ü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 */

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

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

   Mit Glibc erforderliche Feature-Test-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_EMPTY_PATH (seit Linux 5.8)
              Falls   Pfadname   eine   leere   Zeichenkette  ist,  wird  auf  der  durch  Verzdd
              referenzierten Datei gearbeitet (die  mittels  des  Schalters  O_PATH  von  open(2)
              erlangt  worden  sein  kann).  In  diesem  Fall kann sich Verzdd auf jeden Dateityp
              beziehen, nicht nur ein Verzeichnis. Falls Verzdd AT_FDCWD ist, agiert  der  Aufruf
              auf   dem  aktuellen  Arbeitsverzeichnis.  Dieser  Schalter  ist  Linux-spezifisch;
              definieren Sie _GNU_SOURCE, um seine Definition zu erlangen.

       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 gesetzt, um den Fehler anzuzeigen.

FEHLER

       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)).

       EBADF  (faccessat())  Der  Pfadname  ist  relativ,  aber   Verzdd   ist   weder   AT_FDCWD
              (faccessat()) noch ein gültiger Dateideskriptor.

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

       EINVAL Modus wurde falsch angegeben.

       EINVAL (faccessat()) Unzulässiger Schalter in Schalter angegeben.

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

       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.

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

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

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

       EPERM  Es  wurde  Schreibberechtigung  für  eine  Datei  abgefragt,   die   den   Schalter
              unveränderlich (»immutable«) gesetzt hat. Siehe auch ioctl_iflags(2).

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

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

VERSIONEN

       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.

   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.

STANDARDS

       access()
       faccessat()
              POSIX.1-2008.

       faccessat2()
              Linux.

GESCHICHTE

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

       faccessat()
              Linux 2.6.16, Glibc 2.4.

       faccessat2()
              Linux 5.8.

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.

       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 gemeldet 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.

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.

       In Linux 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.6er  Linuxe  (bis  einschließlich
       Linux 2.6.3) verhielten sich in der gleichen Weise wie 2.4er Linuxe.

       Vor Linux 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 Linux 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)

Ü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⟩.