.\" -*- 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 "5 lutego 2023 r." "Linux man\-pages 6.05.01" 
.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.
.PP
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].
.PP
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).
.PP
Ś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.
.PP
Jeśli proces nie posiada uprawnień wyszukiwania w bieżącym katalogu
wyszukiwania, zwracany jest błąd \fBEACCES\fP (\[Bq]Odmówiono dostępu\[rq]).
.PP
Jeśli składowa ścieżki nie zostanie odnaleziona, zwracany jest błąd
\fBENOENT\fP (\[Bq]Brak podanego pliku lub katalogu\[rq]).
.PP
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]).
.PP
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.
.PP
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]).
.PP
.\"
.\" 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ę.
.PP
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.
.PP
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.
.PP
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.
.PP
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].
.PP
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.
.PP
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.
.PP
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).
.PP
(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))
.PP
.\" 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.
.PP
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).
.PP
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.
.PP
.\" 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
Autorami polskiego tłumaczenia niniejszej strony podręcznika są:
Michał Kułach <michal.kulach@gmail.com>
.
.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 .
