Provided by: manpages-de-dev_4.21.0-2_all 
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_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
faccessat() wurde zu Linux 2.6.16 hinzugefügt; Bibliotheksunterstützung wurde in Glibc 2.4 hinzugefügt.
faccessat2() wurde zu Linux 5.8 hinzugefügt.
STANDARDS
access(): SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
faccessat(): POSIX.1-2008.
faccessat2(): Linux-spezifisch.
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.
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 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.
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.
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⟩.