Provided by: manpages-pl-dev_4.23.1-1_all 
NAZWA
access, faccessat, faccessat2 - sprawdza prawa użytkownika do pliku
BIBLIOTEKA
Standardowa biblioteka C (libc, -lc)
SKŁADNIA
#include <unistd.h> int access(const char *pathname, int mode); #include <fcntl.h> /* Definicja stałych AT_* */ #include <unistd.h> int faccessat(int dirfd, const char *pathname, int mode, int flags); /* Różnice między biblioteką C a jądrem opisano poniżej */ #include <fcntl.h> /* Definicja stałych AT_* */ #include <sys/syscall.h> /* Definicja stałych SYS_* */ #include <unistd.h> int syscall(SYS_faccessat2, int dirfd, const char *pathname, int mode, int flags); Wymagane ustawienia makr biblioteki glibc (patrz feature_test_macros(7)): faccessat(): Od glibc 2.10: _POSIX_C_SOURCE >= 200809L Przed glibc 2.10: _ATFILE_SOURCE
OPIS
access() sprawdza, czy wywołujący proces ma dostęp do pliku pathname. Jeśli pathname jest dowiązaniem
symbolicznym, jest rozwiązywana.
Mode określa jakie sprawdzenia dostępności mają być wykonane i jest albo wartością F_OK albo maską
zawierającą sumę logiczną jednego lub więcej z R_OK, W_OK i X_OK. F_OK sprawdza istnienie pliku. R_OK,
W_OK i X_OK sprawdzają pod kątem istnienia pliku i, odpowiednio, uprawnień odczytu, zapisu i wykonania.
Sprawdzenie jest wykonywane za pomocą prawdziwych identyfikatorów użytkownika i grupy procesu, zamiast
identyfikatorów efektywnych, jak dzieje się przy rzeczywistej próbie wykonania operacji (np. open(2)) na
pliku. Podobnie, w przypadku użytkownika root, sprawdzenie używa zestawu przywilejów (ang. capabilities)
dozwolonych zamiast zestawu przywilejów efektywnych; w przypadku użytkowników innych niż root,
sprawdzenie używa pustego zestawu przywilejów.
Pozwala to programom korzystającym z ustawienia ID użytkownika podczas wykonania (suid) oraz programom
obsługującym przywileje (ang. capabilities) na łatwe określenie uprawnień wywołującego użytkownika.
Innymi słowy, access() nie odpowiada na pytanie "czy mogę odczytać/zapisać/wykonać ten plik?". Odpowiada
na nieco inne "(zakładając, że jestem plikiem wykonywalnym korzystającym z suid) czy użytkownik, który
mnie wywołał może odczytać/zapisać/wykonać ten plik?". Daje to programom korzystającym z suid możliwość
uniemożliwienia zmuszania ich przez złośliwych użytkowników do odczytywania plików, których ci
użytkownicy nie powinni móc odczytywać.
Jeśli wywołujący proces jest uprzywilejowany (tzn. jego identyfikator użytkownika wynosi zero), to
sprawdzenie X_OK kończy się sukcesem, jeśli zwykły plik posiada uprawnienie wykonania dla dowolnego
właściciela pliku, grupy itp.
faccessat()
Wywołanie systemowe faccessat() operuje w dokładnie taki sam sposób jak access(), z wyjątkiem różnic
opisanych tutaj.
Jeśli ścieżka podana w pathname jest względna, jest to interpretowane w odniesieniu do katalogu do
którego odnosi się deskryptor pliku dirfd (zamiast w odniesieniu do bieżącego katalogu roboczego procesu
wywołującego, jak w stosunku do ścieżek względnych robi to access()).
Jeśli pathname jest względna a dirfd ma wartość specjalną AT_FDCWD, to pathname jest interpretowana w
odniesieniu do bieżącego katalogu roboczego procesu wywołującego (jak access()).
Jeśli ścieżka pathname jest bezwzględna, to dirfd jest ignorowane.
Parametr flags jest tworzony jako suma logiczna (OR) zera lub większej liczby następujących wartości:
AT_EACCESS
Przeprowadza sprawdzenie za pomocą efektywnych identyfikatorów użytkownika i grupy. Domyślnie
faccessat() używa identyfikatorów rzeczywistych (jak access()).
AT_EMPTY_PATH (od Linuksa 5.8)
Jeśli pathname jest pustym łańcuchem, działa na pliku do którego odnosi się dirfd (który mógł być
pozyskany za pomocą znacznika O_PATH open(2)). W tym przypadku dirfd może odnosić się do dowolnego
typu pliku, a nie tylko katalogu. Jeśli dirfd wynosi AT_FDCWD, to wywołanie działa na bieżącym
katalogu roboczym. Znacznik ten jest charakterystyczny dla Linuksa; należy zdefiniować
_GNU_SOURCE, aby pozyskać jego definicję.
AT_SYMLINK_NOFOLLOW
Jeśli pathname jest dowiązaniem symbolicznym, nie rozwiązuje go: w zamian zwraca informacje o
samym dowiązaniu.
Więcej informacji o potrzebie wprowadzenia faccessat() można znaleźć w podręczniku openat(2).
faccessat2()
Powyższy opis faccessat() odnosi się do POSIX.1 i implementacji dostarczonej przez glibc. Implementacja
glibc nie była jednak wiernym odwzorowaniem (zob. USTERKI), która prześlizgnęła się nad faktem, że surowe
wywołanie linuksowe faccessat() nie posiadało argumentu flags. W celu poprawnej implementacji, Linux 5.8
dodał wywołanie systemowe faccessat2(), które obsługuje argument flags i pozwala na prawidłową
implementację funkcji opakowującej faccessat().
WARTOŚĆ ZWRACANA
Gdy wszystko pójdzie dobrze (wszystkie żądane prawa są zapewnione, lub mode wynosi F_OK i plik istnieje),
zwracane jest zero. W wypadku błędu (przynajmniej jeden bit z żądanych w mode uprawnień nie jest
ustawiony, mode wynosi F_OK i plik nie istnieje lub wystąpiły inne błędy), zwracane jest -1 i ustawiane
jest errno wskazując błąd.
BŁĘDY
EACCES Brak uprawnień dla żądanego dostępu do pliku, albo brak uprawnień do przeglądania któregoś z
katalogów w ścieżce pathname (zob. też path_resolution(7)).
EBADF (faccessat()) pathname jest względne, lecz dirfd nie wynosi ani AT_FDCWD (faccessat()), ani nie
jest prawidłowym deskryptorem pliku.
EFAULT pathname wskazuje poza dostępną dla użytkownika przestrzeń adresową.
EINVAL mode zostało nieprawidłowo podane.
EINVAL (faccessat()) Podano nieprawidłową opcję w flags.
EIO Wystąpił błąd wejścia/wyjścia.
ELOOP Podczas rozwiązywania pathname napotkano zbyt wiele dowiązań symbolicznych.
ENAMETOOLONG
Ścieżka pathname jest zbyt długa.
ENOENT Składnik pathname nie istnieje lub jest wiszącym dowiązaniem symbolicznym.
ENOMEM Brak pamięci jądra.
ENOTDIR
Składnik pathname, który powinien być katalogiem w rzeczywistości katalogiem nie jest.
ENOTDIR
(faccessat()) pathname jest względna a dirfd jest deskryptorem pliku odnoszącym się do pliku
zamiast do katalogu.
EPERM Żądano zapisu do pliku z ustawionym znacznikiem niezmienności. Zob. też ioctl_iflags(2).
EROFS Żądano zapisu do pliku położonego w systemie plików tylko do odczytu.
ETXTBSY
Wystąpiła próba dostępu z prawem zapisu do pliku aktualnie uruchomionego programu.
WERSJE
Jeśli proces posiada odpowiednie uprawnienia (tj. jest superużytkownikiem), POSIX.1-2001 zezwala na
implementację wskazującą pomyślne zakończenie dla sprawdzenia X_OK nawet wtedy, gdy nie jest ustawiony
żaden z bitów uruchamialności w prawach dostępu do pliku. Linux tego nie czyni.
Różnice biblioteki C/jądra
Surowe wywołanie systemowe faccessat() przyjmuje jedynie trzy pierwsze argumenty. Znaczniki AT_EACCESS i
AT_SYMLINK_NOFOLLOW są faktycznie zaimplementowane w opakowującej funkcji glibc do faccessat(). Jeśli nie
podano żadnego z tych znaczników, funkcja opakowująca używa fstatat(2) do określenia uprawnień dostępu,
zob. jednak USTERKI.
Uwagi dla glibc
Na starszych wersjach jądra Linux, gdzie faccessat() nie jest dostępne (i gdzie znaczniki AT_EACCESS oraz
AT_SYMLINK_NOFOLLOW nie są określone), funkcja opakowująca z glibc wraca do używania access(). Gdy
pathname jest względną ścieżką, glibc konstruuje ścieżkę na bazie dowiązania symbolicznego w
/proc/self/fd, które odpowiada argumentowi dirfd.
STANDARDY
access()
faccessat()
POSIX.1-2008.
faccessat2()
Linux.
HISTORIA
access()
SVr4, 4.3BSD, POSIX.1-2001.
faccessat()
Linux 2.6.16, glibc 2.4.
faccessat2()
Linux 5.8.
UWAGI
Ostrzeżenie: Użycie tych wywołań w celu sprawdzenia, czy użytkownik ma uprawnienia na przykład do
otwarcia pliku, przed otwarciem tego pliku za pomocą open(2) tworzy lukę bezpieczeństwa, ponieważ
użytkownik może wykorzystać krótki moment pomiędzy sprawdzeniem pliku a otwarciem go do manipulacji na
pliku. Z tego powodu należy unikać używania niniejszego wywołania systemowego (w opisanym właśnie
przykładzie, bezpieczniejszą alternatywą byłoby tymczasowe przełączenie efektywnego identyfikatora
użytkownika na jego identyfikator rzeczywisty, a następnie wywołanie open(2)).
access() zawsze podąża za dowiązaniami symbolicznymi. Jeśli konieczne jest sprawdzenie uprawnień samego
dowiązania symbolicznego, należy użyć faccessat() ze znacznikiem AT_SYMLINK_NOFOLLOW.
Te wywołania zwracają błąd, jeśli jakikolwiek z żądanych w mode rodzajów dostępu zostanie odmówiony,
nawet jeśli pozostałe typy dostępu z mode są dozwolone.
Plik jest dostępny tylko wówczas, gdy uprawnienia każdego z katalogów w jego ścieżce pathname przyznają
dostęp do przeszukiwania (tj. wykonania). Jeśli dowolny katalog jest niedostępny, to wywołanie access()
zawiedzie, niezależnie od uprawnień samego pliku.
Sprawdzane są jedynie bity dostępu, nie zawartość pliku czy jego typ. Dlatego, jeśli katalog okazuje się
"zapisywalny", znaczy to prawdopodobnie, że można w nim tworzyć pliki, a nie, że do katalogu można pisać
jak do pliku. Podobnie, plik dosowy może zostać zgłoszony jako "wykonywalny", lecz funkcja execve(2) mimo
to zawiedzie.
Wywołania te mogą nie działać prawidłowo na systemach plików NFSv2 z włączonym mapowaniem UID, ponieważ
mapowanie to jest dokonywane na serwerze i ukryte przed klientem sprawdzającym prawa dostępu (NFS w
wersji 3 i wyższej dokonują sprawdzeń na serwerze). Podobny problem może wystąpić przy montowaniach FUSE.
USTERKI
Ze względu na to, że wywołanie systemowe jądra Linux faccessat() nie obsługuje argumentu flags, funkcja
opakowująca faccessat() z glibc udostępniona w glibc 2.32 i wcześniejszych, emuluje wymaganą
funkcjonalność za pomocą połączenia wywołania systemowego faccessat() oraz fstatat(2). Jednak emulacja ta
nie bierze pod uwagę ACL-i (list kontroli dostępu do plików). Począwszy od glibc 2.33, funkcja
opakowująca obchodzi tę usterkę, wykorzystując wywołanie systemowe faccessat2(), tam gdzie jest ono
zapewnione przez jądro.
W Linuksie 2.4 (i wcześniejszych) obsługa testów X_OK dla superużytkownika jest nieco dziwna. Jeśli
wszystkie kategorie uprawnień wykonania są wyłączone dla pliku niebędącego katalogiem, to jedynym testem
access() zwracającym -1 jest sytuacja, gdy podany mode wynosi tylko X_OK; jeśli w mode określono również
R_OK lub W_OK, to access() zwróci dla takich plików 0. Wczesny Linux 2.6 (do Linuksa 2.6.3 włącznie)
zachowywał się również w ten sam sposób jak Linux 2.4.
Przed Linuksem 2.6.20, wywołania te ignorowały wpływ znacznika MS_NOEXEC, jeśli był on używany do
wykonania mount(2) na systemie plików. Od Linuksa 2.6.20, znacznik MS_NOEXEC jest uwzględniany.
ZOBACZ TAKŻE
chmod(2), chown(2), open(2), setgid(2), setuid(2), stat(2), euidaccess(3), credentials(7), path_resolution(7), symlink(7)
TŁUMACZENIE
Autorami polskiego tłumaczenia niniejszej strony podręcznika są: Przemek Borys <pborys@dione.ids.pl>, Andrzej Krzysztofowicz <ankry@green.mf.pg.gda.pl> i Michał Kułach <michal.kulach@gmail.com> Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z GNU General Public License w wersji 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI. Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej ⟨manpages-pl- list@lists.sourceforge.net⟩.