path_resolution(7)     Miscellaneous Information Manual     path_resolution(7)

NUME
       path_resolution - modul in care un nume de ruta este rezolvat pentru un
       fi<?>ier

DESCRIERE
       Unele apeluri de sistem UNIX/Linux au ca parametru unul sau mai multe
       nume de fi<?>iere. Un nume de fi<?>ier (sau nume de ruta) se rezolva
       dupa cum urmeaza.

   Pasul 1: ini<?>ierea procesului de solu<?>ionare
       In cazul in care numele de ruta incepe cu caracterul ,,/", directorul
       de cautare de pornire este directorul radacina al procesului de
       apelare. Un proces mo<?>tene<?>te directorul radacina de la parintele
       sau. De obicei, acesta va fi directorul radacina al ierarhiei de
       fi<?>iere. Un proces poate ob<?>ine un alt director radacina prin
       utilizarea apelului de sistem chroot(2) sau poate utiliza temporar un
       alt director radacina prin utilizarea openat2(2) cu fanionul
       RESOLVE_IN_ROOT activat.

       Un proces poate ob<?>ine un spa<?>iu de nume de montare complet privat
       in cazul in care acesta sau unul dintre stramo<?>ii sai a fost
       ini<?>iat printr-o invocare a apelului de sistem clone(2) care a avut
       activat fanionul CLONE_NEWNS. Aceasta gestioneaza partea ,,/" din
       numele de ruta.

       Daca numele de ruta nu incepe cu caracterul ,,/", directorul de cautare
       de pornire al procesului de rezolu<?>ie este directorul de lucru curent
       al procesului - sau, in cazul apelurilor de sistem de tip openat(2),
       argumentul dfd (sau directorul de lucru curent daca AT_FDCWD este
       trecut ca argument dfd). Directorul de lucru curent este mo<?>tenit de
       la parintele <?>i poate fi modificat prin utilizarea apelului de sistem
       chdir(2).

       Numele de ruta care incep cu un caracter '/' se numesc nume de ruta
       absolute. Numele de ruta care nu incep cu un caracter '/' se numesc
       nume de ruta relative.

   Pasul 2: parcurgerea rutei
       Stabile<?>te directorul de cautare curent la directorul de cautare
       ini<?>ial.  Acum, pentru fiecare componenta nefinala a numelui de ruta,
       unde o componenta este un sub<?>ir delimitat de caractere ,,/", aceasta
       componenta este cautata in directorul de cautare curent.

       Daca procesul nu are permisiunea de cautare in directorul de cautare
       curent, se trimite o eroare EACCES (,,Permisiune refuzata").

       In cazul in care componenta nu este gasita, se trimite o eroare ENOENT
       (,,Nu exista un astfel de fi<?>ier sau director").

       In cazul in care componenta este gasita, dar nu este nici un director,
       nici o legatura simbolica, se trimite o eroare ENOTDIR (,,Nu este un
       director").

       In cazul in care componenta este gasita <?>i este un director, se
       stabile<?>te directorul de cautare curent la acel director <?>i se
       trece la urmatoarea componenta.

       Daca componenta este gasita <?>i este o legatura simbolica, mai intai
       se rezolva aceasta legatura simbolica (cu directorul de cautare curent
       ca director de cautare ini<?>ial). In caz de eroare, se returneaza
       aceasta eroare. Daca rezultatul nu este un director, se trimite o
       eroare ENOTDIR. In cazul in care rezolvarea legaturii simbolice este
       reu<?>ita <?>i returneaza un director, se stabile<?>te directorul de
       cautare curent in acel director <?>i se trece la urmatoarea componenta.
       Re<?>ine<?>i ca procesul de rezolvare poate implica recursivitate in
       cazul in care componenta de prefix (,,dirname") a unui nume de ruta
       con<?>ine un nume de fi<?>ier care este o legatura simbolica ce se
       rezolva catre un director (unde componenta de prefix a acelui director
       poate con<?>ine o legatura simbolica, <?>i a<?>a mai departe). Pentru a
       proteja nucleul impotriva supraincarcarii stivei <?>i, de asemenea,
       pentru a proteja impotriva refuzului de serviciu, exista limite privind
       adancimea maxima de recursivitate <?>i numarul maxim de legaturi
       simbolice urmate. O eroare ELOOP este returnata atunci cand se
       depa<?>e<?>te limita maxima (,,Prea multe niveluri de legaturi
       simbolice").

       A<?>a cum este implementat in prezent in Linux, numarul maxim de
       legaturi simbolice care vor fi urmate in timpul rezolvarii unui nume de
       ruta este de 40. Inainte de Linux 2.6.18, limita adancimii de
       recursivitate era de 5. Incepand cu Linux 2.6.18, aceasta limita a fost
       ridicata la 8. In Linux 4.2, codul de rezolvare a numelui de ruta din
       nucleu a fost reelaborat pentru a elimina utilizarea recursivita<?>ii,
       astfel incat singura limita care a ramas este limita maxima de 40 de
       rezolvari pentru intregul nume de ruta.

       Rezolvarea legaturilor simbolice in timpul acestei etape poate fi
       blocata prin utilizarea openat2(2), cu fanionul RESOLVE_NO_SYMLINKS
       activat.

   Pasul 3: gasirea intrarii finale
       Cautarea componentei finale a numelui de ruta se face la fel ca <?>i
       cea a celorlalte componente, a<?>a cum a fost descrisa in etapa
       anterioara, cu doua diferen<?>e: (i) componenta finala nu trebuie sa
       fie neaparat un director (cel pu<?>in in ceea ce prive<?>te procesul de
       rezolvare a rutei - ar putea sa fie un director sau un non-director,
       din cauza cerin<?>elor apelului de sistem specific) <?>i (ii) nu este
       neaparat o eroare daca componenta nu este gasita - poate ca tocmai o
       cream. Detaliile privind tratamentul ultimei intrari sunt descrise in
       paginile de manual ale apelurilor de sistem specifice.

   .  <?>i ..
       Prin conven<?>ie, fiecare director are intrarile ,,." <?>i ,,..", care
       se refera la directorul in sine <?>i, respectiv, la directorul parinte.

       Procesul de rezolvare a rutei va presupune ca aceste intrari au
       semnifica<?>ia lor conven<?>ionala, indiferent daca acestea sunt sau nu
       prezente in sistemul de fi<?>iere fizic.

       Nu se poate trece dincolo de radacina: ,,/.." este acela<?>i lucru cu
       ,,/".

   Puncte de montare
       Dupa o comanda mount dev path, numele de ruta ,,path" se refera la
       radacina ierarhiei sistemului de fi<?>iere de pe dispozitivul ,,dev",
       <?>i nu la aceea ce se referea anterior.

       Se poate ie<?>i dintr-un sistem de fi<?>iere montat: ,,ruta/.." se
       refera la directorul parinte al ,,rutei", in afara ierarhiei sistemului
       de fi<?>iere de pe ,,dev".

       Traversarea punctelor de montare poate fi blocata prin utilizarea
       openat2(2), cu fanionul RESOLVE_NO_XDEV activat (re<?>ine<?>i insa ca
       acest lucru restric<?>ioneaza, de asemenea, traversarea montarii
       asociate ,,bind").

   Barele oblice finale
       In cazul in care o ruta de acces se termina cu ,,/", acest lucru
       for<?>eaza rezolvarea componentei precedente ca la pasul 2: componenta
       care precede bara oblica fie exista <?>i se rezolva intr-un director,
       fie nume<?>te un director care urmeaza sa fie creat imediat dupa
       rezolvarea numelui de acces. In caz contrar, se ignora caracterul final
       ,,/".

   Legatura simbolica finala
       In cazul in care ultima componenta a unui nume de ruta este o legatura
       simbolica, atunci depinde de apelul de sistem daca fi<?>ierul la care
       se face referire va fi legatura simbolica sau rezultatul rezolvarii
       rutei in func<?>ie de con<?>inutul sau. De exemplu, apelul de sistem
       lstat(2) va opera asupra legaturii simbolice, in timp ce stat(2)
       opereaza asupra fi<?>ierului indicat de legatura simbolica.

   Limita de lungime
       Exista o lungime maxima pentru numele de ruta. In cazul in care numele
       de ruta (sau un nume de ruta intermediar ob<?>inut in timpul rezolvarii
       legaturilor simbolice) este prea lung, se trimite o eroare ENAMETOOLONG
       (,,Numele fi<?>ierului este prea lung").

   Nume de ruta gol
       In UNIX-ul original, numele de ruta gol se referea la directorul
       curent. In prezent, POSIX decreteaza ca un nume de ruta gol nu trebuie
       sa fie rezolvat cu succes. In acest caz, Linux returneaza ENOENT.

   Permisiuni
       Bi<?>ii de permisiune ai unui fi<?>ier constau din trei grupuri de trei
       bi<?>i; a se vedea chmod(1) <?>i stat(2). Primul grup de trei este
       utilizat atunci cand ID-ul efectiv de utilizator al procesului apelant
       este egal cu ID-ul de proprietar al fi<?>ierului. Al doilea grup de
       trei este utilizat atunci cand ID-ul de grup al fi<?>ierului fie este
       egal cu ID-ul de grup efectiv al procesului care face apelul, fie este
       unul dintre ID-urile de grup suplimentare ale procesului care face
       apelul (a<?>a cum este setat de setgroups(2)). In cazul in care
       niciunul dintre ace<?>tia nu este valabil, se utilizeaza cel de-al
       treilea grup.

       Dintre cei trei bi<?>i utiliza<?>i, primul bit determina permisiunea de
       citire, al doilea permisiunea de scriere, iar ultimul permisiunea de
       executare in cazul fi<?>ierelor obi<?>nuite sau permisiunea de cautare
       in cazul directoarelor.

       Linux utilizeaza fsuid in loc de ID-ul efectiv al utilizatorului pentru
       verificarea permisiunilor. In mod normal, fsuid va fi egal cu ID-ul
       efectiv al utilizatorului, dar fsuid poate fi schimbat prin apelul de
       sistem setfsuid(2).

       (Aici ,,fsuid" inseamna ceva de genul ,,ID utilizator de sistem de
       fi<?>iere" (filesystem user ID). Conceptul a fost necesar pentru
       implementarea unui server NFS in spa<?>iul utilizatorului la un moment
       dat, cand procesele puteau trimite un semnal catre un proces cu
       acela<?>i ID de utilizator efectiv. In prezent, acest concept este
       depa<?>it. Nimeni nu ar trebui sa foloseasca setfsuid(2).)

       In mod similar, Linux utilizeaza fsgid (ID grup de sistem de fi<?>iere,
       ,,filesystem group ID") in locul ID-ului efectiv al grupului. A se
       vedea setfsgid(2).

   Ocolirea verificarilor de permisiuni: superutilizator <?>i capacita<?>i
       Pe un sistem UNIX tradi<?>ional, superutilizatorul (root, ID utilizator
       0) este atotputernic <?>i trece peste toate restric<?>iile de
       permisiune atunci cand acceseaza fi<?>iere.

       In Linux, privilegiile de superutilizator sunt impar<?>ite in
       capacita<?>i (a se vedea capabilities(7)). Doua capacita<?>i sunt
       relevante pentru verificarea permisiunilor de fi<?>iere:
       CAP_DAC_OVERRIDE <?>i CAP_DAC_READ_SEARCH; (un proces are aceste
       capacita<?>i daca fsuid-ul sau este 0).

       Capacitatea CAP_DAC_OVERRIDE anuleaza toate verificarile de permisiuni,
       dar acorda permisiunea de execu<?>ie numai atunci cand cel pu<?>in unul
       dintre cei trei bi<?>i de permisiune de execu<?>ie ai fi<?>ierului este
       activat.

       Capacitatea CAP_DAC_READ_SEARCH acorda permisiunea de citire <?>i
       cautare in directoare <?>i permisiunea de citire in fi<?>ierele
       obi<?>nuite.

CONSULTA<?>I <?>I
       readlink(2), capabilities(7), credentials(7), symlink(7)

TRADUCERE
       Traducerea in limba romana a acestui manual a fost facuta de Remus-
       Gabriel Chelu <remusgabriel.chelu@disroot.org>

       Aceasta traducere este documenta<?>ie gratuita; citi<?>i Licen<?>a
       publica generala GNU Versiunea 3
       <https://www.gnu.org/licenses/gpl-3.0.html> sau o versiune ulterioara
       cu privire la condi<?>ii privind drepturile de autor.  NU se asuma
       NICIO RESPONSABILITATE.

       Daca gasi<?>i erori in traducerea acestui manual, va rugam sa
       trimite<?>i un e-mail la <translation-team-ro@lists.sourceforge.net>.

Pagini de manual de Linux 6.18 8 februarie 2026             path_resolution(7)