oracular (7) path_resolution.7.gz
NUME
path_resolution - modul în care un nume de rută 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 rută) se rezolvă după cum urmează.
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.
CONSULTAȚI ȘI
readlink(2), capabilities(7), credentials(7), symlink(7)
TRADUCERE
Traducerea în limba română a acestui manual a fost făcută de Remus-Gabriel Chelu
<remusgabriel.chelu@disroot.org>
Această traducere este documentație gratuită; citiți Licența publică generală GNU Versiunea 3
⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ sau o versiune ulterioară cu privire la condiții privind
drepturile de autor. NU se asumă NICIO RESPONSABILITATE.
Dacă găsiți erori în traducerea acestui manual, vă rugăm să trimiteți un e-mail la ⟨translation-team-
ro@lists.sourceforge.net⟩.