Pasul 1: inițierea procesului de soluționare¶

În cazul în care numele de rută începe cu caracterul „/”, directorul de căutare de pornire este directorul rădăcină al procesului de apelare. Un proces moștenește directorul rădăcină de la părintele său. De obicei, acesta va fi directorul rădăcină al ierarhiei de fișiere. Un proces poate obține un alt director rădăcină prin utilizarea apelului de sistem chroot(2) sau poate utiliza temporar un alt director rădăcină prin utilizarea openat2(2) cu fanionul RESOLVE_IN_ROOT activat.

Un proces poate obține un spațiu de nume de montare complet privat în cazul în care acesta sau unul dintre strămoșii săi a fost inițiat printr-o invocare a apelului de sistem clone(2) care a avut activat fanionul CLONE_NEWNS. Aceasta gestionează partea „/” din numele de rută.

Dacă numele de rută nu începe cu caracterul „/”, directorul de căutare de pornire al procesului de rezoluție este directorul de lucru curent al procesului - sau, în cazul apelurilor de sistem de tip openat(2), argumentul dfd (sau directorul de lucru curent dacă AT_FDCWD este trecut ca argument dfd). Directorul de lucru curent este moștenit de la părintele și poate fi modificat prin utilizarea apelului de sistem chdir(2).

Numele de rută care încep cu un caracter '/' se numesc nume de rută absolute. Numele de rută care nu încep cu un caracter '/' se numesc nume de rută relative.

Pasul 2: parcurgerea rutei¶

Stabilește directorul de căutare curent la directorul de căutare inițial. Acum, pentru fiecare componentă nefinală a numelui de rută, unde o componentă este un subșir delimitat de caractere „/”, această componentă este căutată în directorul de căutare curent.

Dacă procesul nu are permisiunea de căutare în directorul de căutare curent, se trimite o eroare EACCES („Permisiune refuzată”).

În cazul în care componenta nu este găsită, se trimite o eroare ENOENT („Nu există un astfel de fișier sau director”).

În cazul în care componenta este găsită, dar nu este nici un director, nici o legătură simbolică, se trimite o eroare ENOTDIR („Nu este un director”).

În cazul în care componenta este găsită și este un director, se stabilește directorul de căutare curent la acel director și se trece la următoarea componentă.

Dacă componenta este găsită și este o legătură simbolică, mai întâi se rezolvă această legătură simbolică (cu directorul de căutare curent ca director de căutare inițial). În caz de eroare, se returnează această eroare. Dacă rezultatul nu este un director, se trimite o eroare ENOTDIR. În cazul în care rezolvarea legăturii simbolice este reușită și returnează un director, se stabilește directorul de căutare curent în acel director și se trece la următoarea componentă. Rețineți că procesul de rezolvare poate implica recursivitate în cazul în care componenta de prefix („dirname”) a unui nume de rută conține un nume de fișier care este o legătură simbolică ce se rezolvă către un director (unde componenta de prefix a acelui director poate conține o legătură simbolică, și așa mai departe). Pentru a proteja nucleul împotriva supraîncărcării stivei și, de asemenea, pentru a proteja împotriva refuzului de serviciu, există limite privind adâncimea maximă de recursivitate și numărul maxim de legături simbolice urmate. O eroare ELOOP este returnată atunci când se depășește limita maximă („Prea multe niveluri de legături simbolice”).

Așa cum este implementat în prezent în Linux, numărul maxim de legături simbolice care vor fi urmate în timpul rezolvării unui nume de rută este de 40. Înainte de Linux 2.6.18, limita adâncimii de recursivitate era de 5. Începând cu Linux 2.6.18, această limită a fost ridicată la 8. În Linux 4.2, codul de rezolvare a numelui de rută din nucleu a fost reelaborat pentru a elimina utilizarea recursivității, astfel încât singura limită care a rămas este limita maximă de 40 de rezolvări pentru întregul nume de rută.

Rezolvarea legăturilor simbolice în timpul acestei etape poate fi blocată prin utilizarea openat2(2), cu fanionul RESOLVE_NO_SYMLINKS activat.

Pasul 3: găsirea intrării finale¶

Căutarea componentei finale a numelui de rută se face la fel ca și cea a celorlalte componente, așa cum a fost descrisă în etapa anterioară, cu două diferențe: (i) componenta finală nu trebuie să fie neapărat un director (cel puțin în ceea ce privește procesul de rezolvare a rutei - ar putea să fie un director sau un non-director, din cauza cerințelor apelului de sistem specific) și (ii) nu este neapărat o eroare dacă componenta nu este găsită - poate că tocmai o creăm. Detaliile privind tratamentul ultimei intrări sunt descrise în paginile de manual ale apelurilor de sistem specifice.

. și ..¶

Prin convenție, fiecare director are intrările „.” și „..”, care se referă la directorul în sine și, respectiv, la directorul părinte.

Procesul de rezolvare a rutei va presupune că aceste intrări au semnificația lor convențională, indiferent dacă acestea sunt sau nu prezente în sistemul de fișiere fizic.

Nu se poate trece dincolo de rădăcină: „/..” este același lucru cu „/”.

Puncte de montare¶

După o comandă mount dev path, numele de rută „path” se referă la rădăcina 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: „rută/..” se referă la directorul părinte al „rutei”, în afara ierarhiei sistemului de fișiere de pe „dev”.

Traversarea punctelor de montare poate fi blocată prin utilizarea openat2(2), cu fanionul RESOLVE_NO_XDEV activat (rețineți însă că acest lucru restricționează, de asemenea, traversarea montării asociate „bind”).

Barele oblice finale¶

În cazul în care o rută de acces se termină cu „/”, acest lucru forțează rezolvarea componentei precedente ca la pasul 2: componenta care precede bara oblică fie există și se rezolvă într-un director, fie numește un director care urmează să fie creat imediat după rezolvarea numelui de acces. În caz contrar, se ignoră caracterul final „/”.

Legătura simbolică finală¶

În cazul în care ultima componentă a unui nume de rută este o legătură simbolică, atunci depinde de apelul de sistem dacă fișierul la care se face referire va fi legătura simbolică sau rezultatul rezolvării rutei în funcție de conținutul său. De exemplu, apelul de sistem lstat(2) va opera asupra legăturii simbolice, în timp ce stat(2) operează asupra fișierului indicat de legătura simbolică.

Limita de lungime¶

Există o lungime maximă pentru numele de rută. În cazul în care numele de rută (sau un nume de rută intermediar obținut în timpul rezolvării legăturilor simbolice) este prea lung, se trimite o eroare ENAMETOOLONG („Numele fișierului este prea lung”).

Nume de rută gol¶

În UNIX-ul original, numele de rută gol se referea la directorul curent. În prezent, POSIX decretează că un nume de rută gol nu trebuie să fie rezolvat cu succes. În acest caz, Linux returnează 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 când 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 când 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)). În cazul în care niciunul dintre aceștia nu este valabil, se utilizează cel de-al treilea grup.

Dintre cei trei biți utilizați, primul bit determină permisiunea de citire, al doilea permisiunea de scriere, iar ultimul permisiunea de executare în cazul fișierelor obișnuite sau permisiunea de căutare în cazul directoarelor.

Linux utilizează fsuid în loc de ID-ul efectiv al utilizatorului pentru verificarea permisiunilor. În 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” înseamnă ceva de genul „ID utilizator de sistem de fișiere” (filesystem user ID). Conceptul a fost necesar pentru implementarea unui server NFS în spațiul utilizatorului la un moment dat, când procesele puteau trimite un semnal către un proces cu același ID de utilizator efectiv. În prezent, acest concept este depășit. Nimeni nu ar trebui să folosească setfsuid(2).)

În mod similar, Linux utilizează fsgid (ID grup de sistem de fișiere, „filesystem group ID”) în locul ID-ului efectiv al grupului. A se vedea setfsgid(2).

Ocolirea verificărilor de permisiuni: superutilizator și capacități¶

Pe un sistem UNIX tradițional, superutilizatorul (root, ID utilizator 0) este atotputernic și trece peste toate restricțiile de permisiune atunci când accesează fișiere.

În Linux, privilegiile de superutilizator sunt împărțite în capacități (a se vedea capabilities(7)). Două capacități sunt relevante pentru verificarea permisiunilor de fișiere: CAP_DAC_OVERRIDE și CAP_DAC_READ_SEARCH; (un proces are aceste capacități dacă fsuid-ul său este 0).

Capacitatea CAP_DAC_OVERRIDE anulează toate verificările de permisiuni, dar acordă permisiunea de execuție numai atunci când cel puțin unul dintre cei trei biți de permisiune de execuție ai fișierului este activat.

Capacitatea CAP_DAC_READ_SEARCH acordă permisiunea de citire și căutare în directoare și permisiunea de citire în fișierele obișnuite.