Verificați operația pe fișier, nu un nume rezolvat din nou ulterior
os.Root din Go protejează operații relative la un director. Verificați cursele cu legături simbolice, limitele platformei și remedierile ulterioare relevante.
De 
Paul. Arhitectură și infrastructură
Un nume de fișier care a trecut validarea nu dovedește că operația ulterioară va deschide fișierul dorit. Dacă alt actor poate modifica sistemul de fișiere între verificare și deschidere, același nume poate indica altă destinație. Accesul bazat pe nume nefiabile ar trebui, așadar, să folosească o operație concepută să împiedice ieșirea dintr-un director de încredere, păstrând separat autorizarea aplicației și limitele resurselor.
Privit din noiembrie 2026, articolul echipei Go din 12 martie 2025 despre API-uri rezistente la traversarea directoarelor explica această limită prin os.Root, introdus în Go 1.24. Proiectarea mută protecția în operația relativă la director. Nu izolează întregul proces, iar anunțul inițial nu este o dovadă suficientă pentru alegerea unei versiuni sigure astăzi.
Un șir verificat poate supraviețui situației descrise
Să luăm un importator ipotetic de documente care acceptă un nume relativ. Eliminarea componentelor .. poate preveni o ieșire exprimată simplu în text. Nu spune nimic despre o legătură simbolică deja aflată în directorul de import. Rezolvarea legăturii și verificarea destinației par mai puternice, dar deschiderea obișnuită ulterioară rezolvă din nou calea.
A doua rezolvare creează un interval vulnerabil. Alt actor ar putea înlocui o componentă a directorului cu o legătură după validare. Aplicația folosește atunci un nume scris identic, dar cu altă destinație. Vulnerabilitatea ține de relația dintre două operații și starea modificabilă a sistemului de fișiere, nu doar de o intrare neobișnuită.
De aceea, mai multe verificări ale șirului nu rezolvă neapărat cursa. O verificare consemnează ceva adevărat într-un anumit moment. Dacă operația următoare nu păstrează relația relevantă, programul se bazează pe faptul că sistemul de fișiere rămâne neschimbat. Presupunerea poate fi validă într-o instalare strict controlată, dar ar trebui să intre în modelul de amenințări, nu să rămână o dependență accidentală.
Pentru afacere, consecința poate fi o încredere nejustificată în funcția de import. Permisiunea de a furniza nume de fișiere permite și influențarea datelor pe care serviciul le citește sau înlocuiește. Dacă extragerea poate crea legături, chiar arhiva poate introduce o stare pe care intrările următoare o întâlnesc. Aplicația are nevoie de o regulă despre operația efectivă, nu doar despre textul acceptat de formular.
Un descriptor de director schimbă relația
Articolul din martie descrie deschiderea unui director rădăcină și efectuarea operațiilor relative prin acesta. Contractul urmărit respinge ieșirile prin componente părinte sau legături simbolice, permițând legăturile care rămân în interior. Distincția contează: protecția nu înseamnă neapărat interzicerea tuturor legăturilor ori a tuturor căilor care conțin o componentă părinte.
În proiectarea aplicației, rădăcina devine o dependență explicită a codului care lucrează cu fișiere. În loc să transmiteți unei funcții un șir nerestricționat cu directorul de bază și să îi cereți să combine nume, transmiteți capacitatea de acces componentei care face operația. Astfel se poate verifica mai ușor dacă un pas ulterior revine accidental la accesul fără restricții prin căi.
Descriptorul nu decide cărui client îi aparține documentul. Operația poate rămâne în director și totuși să citească fișierul altui client, dacă directorul le conține pe amândouă. Autorizarea are nevoie de propria limită. O rădăcină aleasă prea larg nu repară această decizie. Alegeți directorul potrivit organizării datelor și verificați permisiunea utilizatorului pentru operația dorită.
Protecția nu limitează nici volumul muncii. Un fișier valid poate fi prea mare, o arhivă acceptată poate avea prea multe intrări, iar o citire permisă poate dezvălui date la care apelantul nu ar trebui să aibă acces. Sunt limite ilustrative de proiectat separat, nu probleme pe care API-ul directorului pretinde că le rezolvă.
Condițiile platformei fac parte din proiectare
Articolul istoric diferențiază explicit implementările. Pentru Unix descrie operații cu descriptori de director și exclude limitarea traversării punctelor de montare, inclusiv a montărilor bind. În Windows, rădăcina deschisă influențează redenumirea și ștergerea. În WASI, protecția depinde de implementare. Pentru GOOS=js, interfața Node lasă curse la validarea legăturilor simbolice; Plan 9 folosește validare lexicală, fără legături simbolice.
Aceste condiții împiedică promisiunea unei izolări universale. Un serviciu care execută programe nefiabile are nevoie de o limită mult mai largă decât un API de fișiere relativ la director. Procesul poate avea în continuare alți descriptori, acces la rețea sau privilegii separate. Restrângerea unui set de operații nu retrage aceste capacități.
Remedierile ulterioare schimbă recomandarea actuală
Baza de vulnerabilități Go înregistrează CVE-2025-22873, o ieșire cu efect limitat: deschiderea directorului părinte în sine, fără conținutul său sau alți strămoși. Înregistrarea indică remedierea ramurii Go 1.24 în versiunea 1.24.3. Înregistrarea a fost publicată la 4 februarie 2026; data ei nu ar trebui confundată cu anunțul inițial al funcționalității.
Înregistrarea ulterioară CVE-2026-39822, publicată la 7 iulie 2026, descrie o ieșire în Unix printr-o legătură simbolică urmată de bară oblică. Enumeră remedieri în 1.25.12 și 1.26.5, plus 1.27.0-rc.2. Sunt repere de remediere pentru acea problemă, nu o afirmație că acestea sunt versiunile preferate astăzi. O instalare reală ar trebui să verifice instrumentele întreținute față de alertele actuale, fără să se oprească la introducerea os.Root.
Păstrați proporția răspunsului
Obiecția cea mai puternică este că aplicația poate accepta doar nume interne fixe, într-un sistem de fișiere pe care actorii nefiabili nu îl pot modifica. În acel cadru restrâns, tratarea obișnuită a căilor, cu restricții potrivite asupra intrărilor, poate fi suficientă. O abstracție nouă fără o amenințare relevantă poate complica întreținerea.
Când intervin nume nefiabile sau conținut modificabil, urmăriți o operație completă: alegerea rădăcinii, autorizarea utilizatorului, deschiderea prin interfața protejată și păstrarea lucrului ulterior în limita dorită. În dezvoltarea software la comandă, cereți explicarea acestui traseu alături de platformă și starea actualizărilor. Un nume curat este o intrare utilă; operația protejată oferă contractul mai puternic.