Waarom 'n OpenVPN-haak nie die lêer langs sy skrip kan vind nie

Hake wat sonder foute loop en tog 'n ontbrekende lêer rapporteer, kyk gewoonlik op die verkeerde plek, nie omdat hulle taak misluk nie. Relatiewe paadjies in 'n skrip word teen die proses se werkmap opgelos, en 'n diens begin met 'n werkmap wat jy nie gekies het nie. Die lêer langs die skrip en die lêer wat die proses oopmaak, is net dieselfde ding wanneer iets hulle anker. Daardie gaping verklaar 'n groot deel van haakfoute wat verkeerd as toestemmingsprobleme gelees word.

Kontroleer die pad voor die toestemmings, want 'n toestemmingsfout op die verkeerde lêer bly die verkeerde lêer.

'n Relatiewe pad word teen die proses opgelos, nie teen die lêer nie

Wanneer 'n skrip open("policy.json"), los die kernel die naam teen die proses se huidige werkmap op. Niks van die skrip se eie ligging neem aan daardie soektog deel nie. OpenVPN begin hake vanuit 'n gids wat hy self kies, en die cd -opsie kan dit verander, so 'n skrip wat met die hand vanuit sy eie vouer getoets is, gedra hom anders sodra die daemon dit loop. Die handtoets slaag, die diensloop misluk, en die logreël noem net die ontbrekende naam.

Python stel die skrip se ligging bloot as __file__, wat 'n anker moontlik maak. Path(__file__).resolve().parent / "policy.json" bou 'n pad uit die lêer eerder as uit die proses. Daardie een reël verwyder die afhanklikheid van die werkmap sonder om enigiets aan voorregte te verander.

Anker die pad doelbewus en kyk dan wat resolve doen

resolve() volg simboolskakels, so 'n installasie wat die haak in plek skakel, anker by die skakelteiken, nie by die gids wat die skakel bevat nie. Dit is gewoonlik wat jy vir 'n weergawe-ontplooiing wil hê, en dit is verkeerd vir 'n uitleg wat data langs die simboolskakel verwag. Besluit wat die ontplooiing bedoel, en skryf die kode om daarby te pas eerder as om die verskil in produksie te ontdek. Path(__file__).parent sonder resolve() hou die skakel se eie gids.

As die data aan die instansie eerder as aan die program behoort, neem 'n absolute pad uit die konfigurasie. Om 'n ligging hard te kodeer, koppel die haak aan een gasheeruitleg.

Stap vier grense in volgorde deur

Begin met die werkmap: vergelyk die eenheid se WorkingDirectory, OpenVPN se cd -opsie, en enige omhulsel wat die gids voor exec verander. Bevestig dan die opgeloste ligging, want 'n soortgelyk genoemde lêer in 'n ander ontplooiing kan die soektog beantwoord en die fout verberg. Volgende kom die lêerstelsel-aansig: 'n chroot of 'n diens-mountnaamruimte kan 'n absolute gasheerpad eenvoudig laat ontbreek. Laaste is die toegangsidentiteit, wat 'n aparte vraag van sigbaarheid is.

ProtectHome en PrivateTmp verberg verskillende liggings, en nie een wys in 'n gidslys wat van die gasheer geneem is nie. 'n Pad wat vir root in 'n dop bestaan, kan binne die eenheid se naamruimte onsigbaar wees, en daarom bewys dit so min om dieselfde opdrag buite die diens te toets.

Maak die soektog reg sonder om die diens te verbreed

Om die pad te anker, los net die eerste grens op. Dit stel nie 'n gids bloot wat die diens verberg nie, en dit gee nie 'n onbevoorregte rekening toegang tot 'n lêer wat net root mag lees nie. Die verhoging van script-security verander watter skripte OpenVPN sal loop; dit het geen invloed op waar 'n relatiewe naam opgelos word nie. Om die werkmap vir die hele diens te verander, is breër as die probleem, want elke ander relatiewe sertifikaat-, log- of hulppad skuif saam.

Verkies die eng oplossing: 'n deterministiese pad in die skrip, 'n eksplisiete konfigurasiewaarde vir instansiedata, en lêereienaarskap wat pas by die rekening waaronder die haak werklik loop.

Teken bewyse aan wat die grens benoem

'n Nuttige foutverslag bevat drie dinge: die presiese pad wat die haak probeer het, die omgewing wat dit voortgebring het, en watter grens geweier het. Druk die opgeloste pad en die uitsondering sonder om die lêer se inhoud te stort. Daardie drietal skei 'n verkeerde anker van 'n verborge mount en van 'n toestemmingsweiering, wat drie verskillende regstellings is.

Die bewering dat root die lêer vanaf 'n terminal kan lees, beantwoord een van daardie vrae en nie een van die ander nie. Toets eerder vanuit die diens se eie konteks.