NAZWA

       path_resolution - sposób rozwiązywania ścieżki do pliku

OPIS

       Część  wywołań  systemowych  Uniksa/Linuksa  posiada  jako  parametr jedną lub więcej nazw
       pliku. Nazwa pliku (lub ścieżka) jest rozwiązywana w opisany poniżej sposób.

   Krok 1: początek procesu rozwiązywania
       Jeśli ścieżka zaczyna się znakiem „/”, początkowym katalogiem  wyszukiwania  jest  katalog
       główny  procesu  wywołującego.  Proces  ten  dziedziczy  swój  katalog  główny  od procesu
       macierzystego. Zwykle będzie to korzeń hierarchii plików.  Proces  może  uzyskać  odmienny
       katalog  główny  za  pomocą  wywołania  systemowego  chroot(2)  lub tymczasowo korzystać z
       odmiennego   katalogu   głównego   używając   openat2(2),   z    ustawionym    znacznikiem
       RESOLVE_IN_ROOT.

       Proces  może  posiadać  całkowicie  prywatną przestrzeń nazw montowania, jeśli był on (lub
       jeden z jego przodków) uruchomiony za pomocą wywołania systemowego clone(2)  z  ustawionym
       znacznikiem CLONE_NEWNS. Na tym wyczerpaliśmy opis obsługi fragmentu ścieżki „/”.

       Jeśli  ścieżka nie zaczyna się znakiem „/”, początkowym katalogiem wyszukiwania w procesie
       rozwiązywania będzie bieżący katalog roboczy procesu lub, w przypadku wywołań  systemowych
       z  grupy  openat(2),  argument  dfd  (lub bieżący katalog roboczy, jeśli jako dfd poda się
       AT_FDCWD). Bieżący katalog roboczy jest dziedziczony od procesu macierzystego i  można  go
       zmienić za pomocą wywołania systemowego chdir(2).

       Ścieżki  zaczynające  się  znakiem  „/”  są  nazywane  ścieżkami  absolutnymi. Ścieżki nie
       zaczynające się znakiem „/” są nazywane ścieżkami względnymi.

   Krok 2: przejście przez ścieżkę
       Następuje ustawienie bieżącego katalogu wyszukiwania na początkowy  katalog  wyszukiwania.
       Teraz,   każda  niekońcowa  składowa  ścieżki,  gdzie  składową  ścieżki  jest  podłańcuch
       ograniczony znakami „/”, jest wyszukiwana w bieżącym katalogu wyszukiwania.

       Jeśli proces nie posiada uprawnień wyszukiwania w bieżącym katalogu wyszukiwania, zwracany
       jest błąd EACCES („Odmówiono dostępu”).

       Jeśli składowa ścieżki nie zostanie odnaleziona, zwracany jest błąd ENOENT („Brak podanego
       pliku lub katalogu”).

       Jeśli  składowa  ścieżki  jest  odnaleziona,  ale  nie  jest  katalogiem  ani  dowiązaniem
       symbolicznym, zwracany jest błąd ENOTDIR („Nie jest katalogiem”).

       Jeśli  składowa  ścieżki  jest odnaleziona i jest katalogiem, bieżący katalog wyszukiwania
       jest ustawiony na ten katalog i następuje przejście do następnej składowej ścieżki.

       Jeśli składowa ścieżki jest odnaleziona i jest dowiązaniem symbolicznym, to najpierw  jest
       ona  rozwiązywana  (jako  początkowy  katalog  wyszukiwania  używany  jest bieżący katalog
       wyszukiwania). W razie wystąpienia błędu, jest on zwracany. Jeśli  wynik  rozwiązania  nie
       jest  katalogiem,  zwracany  jest  błąd  ENOTDIR.  Jeśli  proces  rozwiązywania dowiązania
       symbolicznego  powiedzie  się,  zwracając  katalog,  bieżący  katalog  wyszukiwania   jest
       ustawiony  na  ten  katalog  i  następuje przejście do następnej składowej ścieżki. Proszę
       zauważyć, że  proces  rozwiązywania  może  być  rekurencyjny,  jeśli  część  przedrostkowa
       („dirname”)  ścieżki  zawiera nazwę pliku będącego dowiązaniem symbolicznym wskazującym na
       katalog (gdzie część przedrostkowa tego katalogu może znów zawierać dowiązanie symboliczne
       itd.).  Aby zabezpieczyć jądro przed przepełnieniem stosu oraz zapobiec odmówieniu usługi,
       występują ograniczenia maksymalnej głębokości rekurencji oraz maksymalnej liczby  dowiązań
       symbolicznych,  za  którymi następuje podążanie. Po przekroczeniu tych ograniczeń zwracany
       jest błąd ELOOP („Zbyt wiele poziomów dowiązań symbolicznych”).

       Obecna implementacja w Linuksie przewiduje maksymalną liczbę 40 dowiązań symbolicznych, za
       którymi  następuje  podążanie  przy  rozwiązywaniu  ścieżki.  Przed  Linuksem 2.6.18 limit
       głębokości rekurencji wynosił 5. Od Linuksa 2.6.18 limit podniesiono do 8. W Linuksie 4.2,
       kod  rozwiązujący  ścieżki  na  poziomie  jądra został zmodyfikowany, aby wykluczyć użycie
       rekurencji, dzięki czemu jedynym pozostającym limitem jest 40 podążań na całą ścieżkę.

       Rozwiązywanie dowiązań symbolicznych na tym etapie można zablokować za pomocą  openat2(2),
       z ustawionym znacznikiem RESOLVE_NO_SYMLINKS.

   Krok 3: odnalezienie ostatniego wpisu
       Wyszukanie  ostatniej  składowej  ścieżki  przebiega  tak jak to opisano we wcześniejszych
       etapach dotyczących innych jej składowych, z dwiema różnicami: (i)  końcowa  składowa  nie
       może  być  katalogiem  (przynajmniej  z punktu widzenia procesu rozwiązywania ścieżki – ze
       względu na wymagania danego wywołania  systemowego  być  może  musi  być  to  katalog  lub
       niekatalog)  oraz  (ii) jeśli ostatnia składowa ścieżki nie zostanie odnaleziona, nie musi
       być to błąd – być może jest właśnie  tworzona.  Detale  traktowania  ostatniego  wpisu  są
       opisane w podręczniku systemowym danego wywołania systemowego.

   . i ..
       Zgodnie  z  konwencją, każdy katalog posiada wpisy „.” i „..”, odnoszące się, odpowiednio:
       do samego katalogu oraz do jego katalogu nadrzędnego.

       Proces rozwiązywania  ścieżki  założy,  że  wpisy  te  mają  znaczenie  zgodne  z  opisaną
       konwencją, niezależnie od tego, czy są aktualnie obecne w fizycznym systemie plików.

       Nie da się wyjść poza katalog główny: „/..” ma to samo znaczenie co „/”.

   Punkty montowania
       Po  wykonaniu  polecenia  mount  urządzenie  ścieżka,  „ścieżka”  odnosi  się  do korzenia
       hierarchii systemu plików na „urządzeniu”, a nie do tego, do czego odnosiła się wcześniej.

       Można wyjść poza zamontowany system:  „ścieżka/..”  odnosi  się  do  katalogu  nadrzędnego
       „ścieżki”, poza hierarchią systemu plików na „urządzeniu”.

       Przekraczanie  punktów  montowania  można  zablokować  za  pomocą openat2(2), z ustawionym
       znacznikiem RESOLVE_NO_XDEV (choć dotknie to również przekraczania punktów montowań  przez
       podpięcie (bind)).

   Końcowe ukośniki
       Jeśli ścieżka kończy się na „/”, wymusza to rozwiązanie poprzedzającej jej składowej jak w
       Kroku 2: składowa poprzedzająca ukośnik albo istnieje i rozwiązuje się  na  katalog,  albo
       nazywa  katalog,  który  ma  być  utworzony  natychmiast po rozwiązaniu ścieżki. Poza tym,
       końcowy „/” jest ignorowany.

   Końcowe dowiązanie symboliczne
       Jeśli ostatnia składowa ścieżki jest dowiązaniem symbolicznym, to od wywołania systemowego
       zależy,  czy za docelowy plik zostanie uznane samo dowiązanie symboliczne, czy plik będący
       wynikiem  rozwiązania  ścieżki,  na  który  wskazuje  dowiązanie.  Przykładowo,  wywołanie
       systemowe lstat(2) będzie działać na samym dowiązaniu symbolicznym, a stat(2) na pliku, na
       który wskazuje dowiązanie symboliczne.

   Ograniczenie długości
       Występuje maksymalna długość ścieżki. Jeśli ścieżka (lub  ścieżka  pośrednia,  uzyskana  w
       trakcie  rozwiązywania  dowiązań  symbolicznych)  jest  zbyt  długa,  zwracany  jest  błąd
       ENAMETOOLONG („Nazwa pliku zbyt długa”).

   Pusta ścieżka
       W pierwotnym systemie UNIX, pusta ścieżka odnosiła  się  do  bieżącego  katalogu.  Obecnie
       POSIX  nakazuje,  aby  pusta ścieżka nie była pomyślnie rozwiązywana. Linux zwraca w takim
       przypadku błąd ENOENT.

   Uprawnienia
       Bity uprawnień pliku składają się z trzech trzybitowych grup;  zob.  chmod(1)  i  stat(2).
       Pierwsza  trzybitowa  grupa  jest używana, gdy efektywny identyfikator użytkownika procesu
       wywołującego jest równy identyfikatorowi właściciela pliku. Druga  trzybitowa  grupa  jest
       używana,  gdy  identyfikator grupy pliku albo równa się efektywnemu identyfikatorowi grupy
       procesu wywołującego, albo jest jednym  z  identyfikatorów  grupy  uzupełniającej  procesu
       wywołującego  (jak  ustawionej przez setgroups(2)). Jeśli żadna z dwóch opisanych sytuacji
       nie ma miejsca, używana jest trzecia grupa.

       Z trzech używanych bitów, pierwszy określa uprawnienie do  odczytu,  drugi  do  zapisu,  a
       ostatni  uprawnienie wykonania w przypadku zwykłych plików albo uprawnienie przeszukania w
       przypadku katalogów.

       Linux  używa  fsuid  zamiast  efektywnego  identyfikatora  użytkownika  przy   sprawdzaniu
       uprawnień. Standardowo fsuid powinien równać się identyfikatorowi efektywnemu użytkownika,
       ale fsuid można zmienić wywołaniem systemowym setfsuid(2).

       (Tu „fsuid” oznacza coś jak „identyfikator użytkownika systemu  plików”  (ang.  filesystem
       UID).  Koncept ten był wymagany przez implementację serwera NFS w przestrzeni użytkownika,
       w  czasie,  gdy  procesy  mogły  wysyłać  sygnały  do  procesów  z  tym  samym  efektywnym
       identyfikatorem użytkownika. Jest to przestarzałe. Obecnie nie należy używać setfsuid(2))

       Podobnie,  Linux  używa  fsgid „identyfikatora grupy systemu plików” (ang. filesystem GID)
       zamiast efektywnego identyfikatora grupy. Zob. setfsgid(2).

   Pomijanie sprawdzenia uprawnień: superużytkownik i przywileje
       W tradycyjnym systemie UNIX, superużytkownik (root, użytkownik o  identyfikatorze  0)  był
       wszechmocny i omijał wszelkie ograniczenia wynikające z uprawnień przy dostępie do plików.

       W  Linuksie,  moce  superużytkownika  podzielono  na przywileje (zob. capabilities(7)). Do
       sprawdzenia   uprawnień   pliku   istotne   są   dwa   przywileje:   CAP_DAC_OVERRIDE    i
       CAP_DAC_READ_SEARCH (proces posiada te przywileje, jeśli jego fsuid wynosi 0).

       Przywilej   CAP_DAC_OVERRIDE   przesłania  wszelkie  sprawdzenia  uprawnień,  lecz  nadaje
       uprawnienie wykonania tylko wówczas, gdy ustawiony jest przynajmniej jeden z trzech  bitów
       wykonania pliku.

       Przywilej  CAP_DAC_READ_SEARCH  nadaje  uprawnienia  odczytu i przeszukania katalogów oraz
       uprawnienia odczytu zwykłych plików.

ZOBACZ TAKŻE

       readlink(2), capabilities(7), credentials(7), symlink(7)

TŁUMACZENIE

       Autorami  polskiego  tłumaczenia  niniejszej  strony   podręcznika   są:   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⟩.