.\" -*- coding: UTF-8 -*- .\" Copyright (C) 2003 Andries Brouwer (aeb@cwi.nl) .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH path_resolution 7 "2 maja 2024 r." "Linux man\-pages 6.9.1" .SH NAZWA path_resolution \- sposób rozwiązywania ścieżki do pliku .SH 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. .SS "Krok 1: początek procesu rozwiązywania" Jeśli ścieżka zaczyna się znakiem \[Bq]/\[rq], 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 \fBchroot\fP(2) lub tymczasowo korzystać z odmiennego katalogu głównego używając \fBopenat2\fP(2), z ustawionym znacznikiem \fBRESOLVE_IN_ROOT\fP. .P 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 \fBclone\fP(2) z ustawionym znacznikiem \fBCLONE_NEWNS\fP. Na tym wyczerpaliśmy opis obsługi fragmentu ścieżki \[Bq]/\[rq]. .P Jeśli ścieżka nie zaczyna się znakiem \[Bq]/\[rq], początkowym katalogiem wyszukiwania w procesie rozwiązywania będzie bieżący katalog roboczy procesu lub, w przypadku wywołań systemowych z grupy \fBopenat\fP(2), argument \fIdfd\fP (lub bieżący katalog roboczy, jeśli jako \fIdfd\fP poda się \fBAT_FDCWD\fP). Bieżący katalog roboczy jest dziedziczony od procesu macierzystego i można go zmienić za pomocą wywołania systemowego \fBchdir\fP(2). .P Ścieżki zaczynające się znakiem \[Bq]/\[rq] są nazywane ścieżkami absolutnymi. Ścieżki nie zaczynające się znakiem \[Bq]/\[rq] są nazywane ścieżkami względnymi. .SS "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 \[Bq]/\[rq], jest wyszukiwana w bieżącym katalogu wyszukiwania. .P Jeśli proces nie posiada uprawnień wyszukiwania w bieżącym katalogu wyszukiwania, zwracany jest błąd \fBEACCES\fP (\[Bq]Odmówiono dostępu\[rq]). .P Jeśli składowa ścieżki nie zostanie odnaleziona, zwracany jest błąd \fBENOENT\fP (\[Bq]Brak podanego pliku lub katalogu\[rq]). .P Jeśli składowa ścieżki jest odnaleziona, ale nie jest katalogiem ani dowiązaniem symbolicznym, zwracany jest błąd \fBENOTDIR\fP (\[Bq]Nie jest katalogiem\[rq]). .P 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. .P 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 \fBENOTDIR\fP. 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 (\[Bq]dirname\[rq]) ś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 \fBELOOP\fP (\[Bq]Zbyt wiele poziomów dowiązań symbolicznych\[rq]). .P .\" .\" presently: max recursion depth during symlink resolution: 5 .\" max total number of symbolic links followed: 40 .\" _POSIX_SYMLOOP_MAX is 8 .\" MAXSYMLINKS is 40 .\" MAX_NESTED_LINKS .\" commit 894bc8c4662ba9daceafe943a5ba0dd407da5cd3 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ę. .P Rozwiązywanie dowiązań symbolicznych na tym etapie można zablokować za pomocą \fBopenat2\fP(2), z ustawionym znacznikiem \fBRESOLVE_NO_SYMLINKS\fP. .SS "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 \[en] 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 \[en] być może jest właśnie tworzona. Detale traktowania ostatniego wpisu są opisane w podręczniku systemowym danego wywołania systemowego. .SS "\&. i .." Zgodnie z konwencją, każdy katalog posiada wpisy \[Bq].\[rq] i \[Bq]..\[rq], odnoszące się, odpowiednio: do samego katalogu oraz do jego katalogu nadrzędnego. .P 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. .P Nie da się wyjść poza katalog główny: \[Bq]/..\[rq] ma to samo znaczenie co \[Bq]/\[rq]. .SS "Punkty montowania" Po wykonaniu polecenia \fImount urządzenie ścieżka\fP, \[Bq]ścieżka\[rq] odnosi się do korzenia hierarchii systemu plików na \[Bq]urządzeniu\[rq], a nie do tego, do czego odnosiła się wcześniej. .P Można wyjść poza zamontowany system: \[Bq]ścieżka/..\[rq] odnosi się do katalogu nadrzędnego \[Bq]ścieżki\[rq], poza hierarchią systemu plików na \[Bq]urządzeniu\[rq]. .P Przekraczanie punktów montowania można zablokować za pomocą \fBopenat2\fP(2), z ustawionym znacznikiem \fBRESOLVE_NO_XDEV\fP (choć dotknie to również przekraczania punktów montowań przez podpięcie (bind)). .SS "Końcowe ukośniki" Jeśli ścieżka kończy się na \[Bq]/\[rq], 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 \[Bq]/\[rq] jest ignorowany. .SS "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 \fBlstat\fP(2) będzie działać na samym dowiązaniu symbolicznym, a \fBstat\fP(2) na pliku, na który wskazuje dowiązanie symboliczne. .SS "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 \fBENAMETOOLONG\fP (\[Bq]Nazwa pliku zbyt długa\[rq]). .SS "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 \fBENOENT\fP. .SS Uprawnienia Bity uprawnień pliku składają się z trzech trzybitowych grup; zob. \fBchmod\fP(1) i \fBstat\fP(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 \fBsetgroups\fP(2)). Jeśli żadna z dwóch opisanych sytuacji nie ma miejsca, używana jest trzecia grupa. .P 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. .P 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 \fBsetfsuid\fP(2). .P (Tu \[Bq]fsuid\[rq] oznacza coś jak \[Bq]identyfikator użytkownika systemu plików\[rq] (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ć \fBsetfsuid\fP(2)) .P .\" FIXME . say something about filesystem mounted read-only ? Podobnie, Linux używa fsgid \[Bq]identyfikatora grupy systemu plików\[rq] (ang. filesystem GID) zamiast efektywnego identyfikatora grupy. Zob. \fBsetfsgid\fP(2). .SS "Pomijanie sprawdzenia uprawnień: superużytkownik i przywileje" .\" (but for exec at least one x bit must be set) -- AEB .\" but there is variation across systems on this point: for .\" example, HP-UX and Tru64 are as described by AEB. However, .\" on some implementations (e.g., Solaris, FreeBSD), .\" access(X_OK) by superuser will report success, regardless .\" of the file's execute permission bits. -- MTK (Oct 05) W tradycyjnym systemie UNIX, superużytkownik (\fIroot\fP, użytkownik o identyfikatorze 0) był wszechmocny i omijał wszelkie ograniczenia wynikające z uprawnień przy dostępie do plików. .P W Linuksie, moce superużytkownika podzielono na przywileje (zob. \fBcapabilities\fP(7)). Do sprawdzenia uprawnień pliku istotne są dwa przywileje: \fBCAP_DAC_OVERRIDE\fP i \fBCAP_DAC_READ_SEARCH\fP (proces posiada te przywileje, jeśli jego fsuid wynosi 0). .P Przywilej \fBCAP_DAC_OVERRIDE\fP przesłania wszelkie sprawdzenia uprawnień, lecz nadaje uprawnienie wykonania tylko wówczas, gdy ustawiony jest przynajmniej jeden z trzech bitów wykonania pliku. .P .\" FIXME . say something about immutable files .\" FIXME . say something about ACLs Przywilej \fBCAP_DAC_READ_SEARCH\fP nadaje uprawnienia odczytu i przeszukania katalogów oraz uprawnienia odczytu zwykłych plików. .SH "ZOBACZ TAKŻE" \fBreadlink\fP(2), \fBcapabilities\fP(7), \fBcredentials\fP(7), \fBsymlink\fP(7) .PP .SH TŁUMACZENIE Tłumaczenie niniejszej strony podręcznika: Michał Kułach . .PP Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License w wersji 3 .UE lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI. .PP Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej .MT manpages-pl-list@lists.sourceforge.net .ME .