path_resolution(7) Miscellaneous Information Manual path_resolution(7) NAZWA path_resolution - sposob rozwiazywania sciezki do pliku OPIS Czesc wywolan systemowych Uniksa/Linuksa posiada jako parametr jedna lub wiecej nazw pliku. Nazwa pliku (lub sciezka) jest rozwiazywana w opisany ponizej sposob. Krok 1: poczatek procesu rozwiazywania Jesli sciezka zaczyna sie znakiem ,,/", poczatkowym katalogiem wyszukiwania jest katalog glowny procesu wywolujacego. Proces ten dziedziczy swoj katalog glowny od procesu macierzystego. Zwykle bedzie to korzen hierarchii plikow. Proces moze uzyskac odmienny katalog glowny za pomoca wywolania systemowego chroot(2) lub tymczasowo korzystac z odmiennego katalogu glownego uzywajac openat2(2), z ustawionym znacznikiem RESOLVE_IN_ROOT. Proces moze posiadac calkowicie prywatna przestrzen nazw montowania, jesli byl on (lub jeden z jego przodkow) uruchomiony za pomoca wywolania systemowego clone(2) z ustawionym znacznikiem CLONE_NEWNS. Na tym wyczerpalismy opis obslugi fragmentu sciezki ,,/". Jesli sciezka nie zaczyna sie znakiem ,,/", poczatkowym katalogiem wyszukiwania w procesie rozwiazywania bedzie biezacy katalog roboczy procesu lub, w przypadku wywolan systemowych z grupy openat(2), argument dfd (lub biezacy katalog roboczy, jesli jako dfd poda sie AT_FDCWD). Biezacy katalog roboczy jest dziedziczony od procesu macierzystego i mozna go zmienic za pomoca wywolania systemowego chdir(2). Sciezki zaczynajace sie znakiem ,,/" sa nazywane sciezkami absolutnymi. Sciezki nie zaczynajace sie znakiem ,,/" sa nazywane sciezkami wzglednymi. Krok 2: przejscie przez sciezke Nastepuje ustawienie biezacego katalogu wyszukiwania na poczatkowy katalog wyszukiwania. Teraz, kazda niekoncowa skladowa sciezki, gdzie skladowa sciezki jest podlancuch ograniczony znakami ,,/", jest wyszukiwana w biezacym katalogu wyszukiwania. Jesli proces nie posiada uprawnien wyszukiwania w biezacym katalogu wyszukiwania, zwracany jest blad EACCES (,,Odmowiono dostepu"). Jesli skladowa sciezki nie zostanie odnaleziona, zwracany jest blad ENOENT (,,Brak podanego pliku lub katalogu"). Jesli skladowa sciezki jest odnaleziona, ale nie jest katalogiem ani dowiazaniem symbolicznym, zwracany jest blad ENOTDIR (,,Nie jest katalogiem"). Jesli skladowa sciezki jest odnaleziona i jest katalogiem, biezacy katalog wyszukiwania jest ustawiony na ten katalog i nastepuje przejscie do nastepnej skladowej sciezki. Jesli skladowa sciezki jest odnaleziona i jest dowiazaniem symbolicznym, to najpierw jest ona rozwiazywana (jako poczatkowy katalog wyszukiwania uzywany jest biezacy katalog wyszukiwania). W razie wystapienia bledu, jest on zwracany. Jesli wynik rozwiazania nie jest katalogiem, zwracany jest blad ENOTDIR. Jesli proces rozwiazywania dowiazania symbolicznego powiedzie sie, zwracajac katalog, biezacy katalog wyszukiwania jest ustawiony na ten katalog i nastepuje przejscie do nastepnej skladowej sciezki. Prosze zauwazyc, ze proces rozwiazywania moze byc rekurencyjny, jesli czesc przedrostkowa (,,dirname") sciezki zawiera nazwe pliku bedacego dowiazaniem symbolicznym wskazujacym na katalog (gdzie czesc przedrostkowa tego katalogu moze znow zawierac dowiazanie symboliczne itd.). Aby zabezpieczyc jadro przed przepelnieniem stosu oraz zapobiec odmowieniu uslugi, wystepuja ograniczenia maksymalnej glebokosci rekurencji oraz maksymalnej liczby dowiazan symbolicznych, za ktorymi nastepuje podazanie. Po przekroczeniu tych ograniczen zwracany jest blad ELOOP (,,Zbyt wiele poziomow dowiazan symbolicznych"). Obecna implementacja w Linuksie przewiduje maksymalna liczbe 40 dowiazan symbolicznych, za ktorymi nastepuje podazanie przy rozwiazywaniu sciezki. Przed Linuksem 2.6.18 limit glebokosci rekurencji wynosil 5. Od Linuksa 2.6.18 limit podniesiono do 8. W Linuksie 4.2, kod rozwiazujacy sciezki na poziomie jadra zostal zmodyfikowany, aby wykluczyc uzycie rekurencji, dzieki czemu jedynym pozostajacym limitem jest 40 podazan na cala sciezke. Rozwiazywanie dowiazan symbolicznych na tym etapie mozna zablokowac za pomoca openat2(2), z ustawionym znacznikiem RESOLVE_NO_SYMLINKS. Krok 3: odnalezienie ostatniego wpisu Wyszukanie ostatniej skladowej sciezki przebiega tak jak to opisano we wczesniejszych etapach dotyczacych innych jej skladowych, z dwiema roznicami: (i) koncowa skladowa nie moze byc katalogiem (przynajmniej z punktu widzenia procesu rozwiazywania sciezki - ze wzgledu na wymagania danego wywolania systemowego byc moze musi byc to katalog lub niekatalog) oraz (ii) jesli ostatnia skladowa sciezki nie zostanie odnaleziona, nie musi byc to blad - byc moze jest wlasnie tworzona. Detale traktowania ostatniego wpisu sa opisane w podreczniku systemowym danego wywolania systemowego. . i .. Zgodnie z konwencja, kazdy katalog posiada wpisy ,,." i ,,..", odnoszace sie, odpowiednio: do samego katalogu oraz do jego katalogu nadrzednego. Proces rozwiazywania sciezki zalozy, ze wpisy te maja znaczenie zgodne z opisana konwencja, niezaleznie od tego, czy sa aktualnie obecne w fizycznym systemie plikow. Nie da sie wyjsc poza katalog glowny: ,,/.." ma to samo znaczenie co ,,/". Punkty montowania Po wykonaniu polecenia mount urzadzenie sciezka, ,,sciezka" odnosi sie do korzenia hierarchii systemu plikow na ,,urzadzeniu", a nie do tego, do czego odnosila sie wczesniej. Mozna wyjsc poza zamontowany system: ,,sciezka/.." odnosi sie do katalogu nadrzednego ,,sciezki", poza hierarchia systemu plikow na ,,urzadzeniu". Przekraczanie punktow montowania mozna zablokowac za pomoca openat2(2), z ustawionym znacznikiem RESOLVE_NO_XDEV (choc dotknie to rowniez przekraczania punktow montowan przez podpiecie (bind)). Koncowe ukosniki Jesli sciezka konczy sie na ,,/", wymusza to rozwiazanie poprzedzajacej jej skladowej jak w Kroku 2: skladowa poprzedzajaca ukosnik albo istnieje i rozwiazuje sie na katalog, albo nazywa katalog, ktory ma byc utworzony natychmiast po rozwiazaniu sciezki. Poza tym, koncowy ,,/" jest ignorowany. Koncowe dowiazanie symboliczne Jesli ostatnia skladowa sciezki jest dowiazaniem symbolicznym, to od wywolania systemowego zalezy, czy za docelowy plik zostanie uznane samo dowiazanie symboliczne, czy plik bedacy wynikiem rozwiazania sciezki, na ktory wskazuje dowiazanie. Przykladowo, wywolanie systemowe lstat(2) bedzie dzialac na samym dowiazaniu symbolicznym, a stat(2) na pliku, na ktory wskazuje dowiazanie symboliczne. Ograniczenie dlugosci Wystepuje maksymalna dlugosc sciezki. Jesli sciezka (lub sciezka posrednia, uzyskana w trakcie rozwiazywania dowiazan symbolicznych) jest zbyt dluga, zwracany jest blad ENAMETOOLONG (,,Nazwa pliku zbyt dluga"). Pusta sciezka W pierwotnym systemie UNIX, pusta sciezka odnosila sie do biezacego katalogu. Obecnie POSIX nakazuje, aby pusta sciezka nie byla pomyslnie rozwiazywana. Linux zwraca w takim przypadku blad ENOENT. Uprawnienia Bity uprawnien pliku skladaja sie z trzech trzybitowych grup; zob. chmod(1) i stat(2). Pierwsza trzybitowa grupa jest uzywana, gdy efektywny identyfikator uzytkownika procesu wywolujacego jest rowny identyfikatorowi wlasciciela pliku. Druga trzybitowa grupa jest uzywana, gdy identyfikator grupy pliku albo rowna sie efektywnemu identyfikatorowi grupy procesu wywolujacego, albo jest jednym z identyfikatorow grupy uzupelniajacej procesu wywolujacego (jak ustawionej przez setgroups(2)). Jesli zadna z dwoch opisanych sytuacji nie ma miejsca, uzywana jest trzecia grupa. Z trzech uzywanych bitow, pierwszy okresla uprawnienie do odczytu, drugi do zapisu, a ostatni uprawnienie wykonania w przypadku zwyklych plikow albo uprawnienie przeszukania w przypadku katalogow. Linux uzywa fsuid zamiast efektywnego identyfikatora uzytkownika przy sprawdzaniu uprawnien. Standardowo fsuid powinien rownac sie identyfikatorowi efektywnemu uzytkownika, ale fsuid mozna zmienic wywolaniem systemowym setfsuid(2). (Tu ,,fsuid" oznacza cos jak ,,identyfikator uzytkownika systemu plikow" (ang. filesystem UID). Koncept ten byl wymagany przez implementacje serwera NFS w przestrzeni uzytkownika, w czasie, gdy procesy mogly wysylac sygnaly do procesow z tym samym efektywnym identyfikatorem uzytkownika. Jest to przestarzale. Obecnie nie nalezy uzywac setfsuid(2)) Podobnie, Linux uzywa fsgid ,,identyfikatora grupy systemu plikow" (ang. filesystem GID) zamiast efektywnego identyfikatora grupy. Zob. setfsgid(2). Pomijanie sprawdzenia uprawnien: superuzytkownik i przywileje W tradycyjnym systemie UNIX, superuzytkownik (root, uzytkownik o identyfikatorze 0) byl wszechmocny i omijal wszelkie ograniczenia wynikajace z uprawnien przy dostepie do plikow. W Linuksie, moce superuzytkownika podzielono na przywileje (zob. capabilities(7)). Do sprawdzenia uprawnien pliku istotne sa dwa przywileje: CAP_DAC_OVERRIDE i CAP_DAC_READ_SEARCH (proces posiada te przywileje, jesli jego fsuid wynosi 0). Przywilej CAP_DAC_OVERRIDE przeslania wszelkie sprawdzenia uprawnien, lecz nadaje uprawnienie wykonania tylko wowczas, gdy ustawiony jest przynajmniej jeden z trzech bitow wykonania pliku. Przywilej CAP_DAC_READ_SEARCH nadaje uprawnienia odczytu i przeszukania katalogow oraz uprawnienia odczytu zwyklych plikow. ZOBACZ TAKZE readlink(2), capabilities(7), credentials(7), symlink(7) TLUMACZENIE Autorami polskiego tlumaczenia niniejszej strony podrecznika sa: Michal Kulach Niniejsze tlumaczenie jest wolna dokumentacja. Blizsze informacje o warunkach licencji mozna uzyskac zapoznajac sie z GNU General Public License w wersji 3 lub nowszej. Nie przyjmuje sie ZADNEJ ODPOWIEDZIALNOSCI. Bledy w tlumaczeniu strony podrecznika prosimy zglaszac na adres listy dyskusyjnej . Linux man-pages 6.06 31 pazdziernika 2023 r. path_resolution(7)