De ce un hook OpenVPN nu găsește fișierul de lângă scriptul său

Hookurile care rulează fără eroare și totuși raportează un fișier lipsă se uită de obicei în locul greșit, nu eșuează în sarcina lor. Căile relative dintr-un script sunt rezolvate față de directorul de lucru al procesului, iar un serviciu pornește cu un director de lucru pe care nu l-ați ales. Fișierul de lângă script și fișierul pe care procesul îl deschide sunt același lucru doar când ceva le ancorează. Acest decalaj explică o mare parte din eșecurile hookurilor care sunt citite greșit ca probleme de permisiuni.

Verificați calea înainte de permisiuni, pentru că o eroare de permisiuni pe fișierul greșit rămâne fișierul greșit.

O cale relativă este rezolvată față de proces, nu față de fișier

Când un script apelează open("policy.json"), nucleul rezolvă numele față de directorul de lucru curent al procesului. Nimic din locația scriptului însuși nu participă la acea căutare. OpenVPN pornește hookurile dintr-un director pe care îl alege singur, iar opțiunea cd îl poate schimba, așa că un script testat manual din propriul dosar se comportă diferit când demonul îl execută. Testul manual trece, rularea serviciului eșuează, iar linia de jurnal menționează doar numele lipsă.

Python expune locația scriptului ca __file__, și exact asta face posibilă ancorarea. Path(__file__).resolve().parent / "policy.json" construiește o cale din fișier, nu din proces. Acea singură linie elimină dependența de directorul de lucru fără să schimbe ceva la privilegii.

Ancorați calea intenționat, apoi verificați ce face resolve

resolve() urmează legăturile simbolice, deci o instalare care leagă hookul la locul lui se ancorează la ținta legăturii, nu la directorul care ține legătura. De obicei asta se dorește pentru o implementare versionată și este greșit pentru o configurație care așteaptă date lângă legătura simbolică. Decideți ce înseamnă implementarea și scrieți codul în consecință, în loc să descoperiți diferența în producție. Path(__file__).parent fără resolve() păstrează directorul propriu al legăturii.

Dacă datele aparțin instanței și nu programului, luați o cale absolută din configurație. Codificarea fixă a unei locații leagă hookul de o singură configurație de gazdă.

Parcurgeți patru granițe în ordine

Începeți cu directorul de lucru: comparați WorkingDirectory, opțiunea cd a OpenVPN și orice înveliș care schimbă directorul înainte de exec. Apoi confirmați locația rezolvată, pentru că un fișier cu nume similar într-o altă implementare poate răspunde căutării și poate ascunde eroarea. Urmează vederea sistemului de fișiere: un chroot sau un spațiu de nume de montare al serviciului pot face o cale absolută de gazdă pur și simplu absentă. În final identitatea de acces, care este o întrebare separată de vizibilitate.

ProtectHome și PrivateTmp ascund locații diferite, iar niciuna nu apare într-o listare de director luată de pe gazdă. O cale care există pentru root într-un shell poate fi invizibilă în interiorul spațiului de nume al unității, și de aceea testarea aceleiași comenzi în afara serviciului dovedește atât de puțin.

Reparați căutarea fără a lărgi serviciul

Ancorarea căii rezolvă doar prima graniță. Nu expune un director pe care serviciul îl ascunde și nu acordă unui cont fără privilegii acces la un fișier doar pentru root. Creșterea script-security schimbă ce scripturi va rula OpenVPN; nu are niciun efect asupra locului unde este rezolvat un nume relativ. Schimbarea directorului de lucru pentru tot serviciul este mai largă decât problema, pentru că orice altă cale relativă de certificat, jurnal sau ajutor se mută împreună.

Preferați corecția îngustă: o cale deterministă în script, o valoare explicită de configurație pentru datele instanței și o proprietate a fișierelor care corespunde contului sub care hookul rulează efectiv.

Înregistrați dovezi care numesc granița

Un raport util de eșec conține trei lucruri: calea exactă pe care a încercat-o hookul, mediul care a produs-o și care graniță a refuzat. Tipăriți calea rezolvată și excepția fără a vărsa conținutul fișierului. Acea triplă separă o ancorare greșită de o montare ascunsă și de o refuzare a permisiunii, care sunt trei corecții diferite.

Afirmația că root poate citi fișierul dintr-un terminal răspunde la una dintre acele întrebări și la niciuna dintre celelalte. Testați în schimb din contextul serviciului însuși.