Waarom een OpenVPN-hook het bestand naast zijn script niet vindt

Hooks die zonder fout draaien en toch een ontbrekend bestand melden, kijken meestal op de verkeerde plek, niet dat ze in hun taak falen. Relatieve paden in een script worden tegen de werkmap van het proces opgelost, en een dienst start met een werkmap die u niet hebt gekozen. Het bestand naast het script en het bestand dat het proces opent, zijn alleen hetzelfde wanneer iets ze verankert. Dat gat verklaart een groot deel van de hookfouten die verkeerd als rechtenproblemen worden gelezen.

Controleer het pad vóór de rechten, want een rechtenfout op het verkeerde bestand is nog steeds het verkeerde bestand.

Een relatief pad wordt tegen het proces opgelost, niet tegen het bestand

Wanneer een script open("policy.json") aanroept, lost de kernel de naam op tegen de huidige werkmap van het proces. Niets van de eigen locatie van het script doet aan die zoekactie mee. OpenVPN start hooks vanuit een map die het zelf kiest, en de optie cd kan die wijzigen, dus een script dat met de hand vanuit zijn eigen map is getest, gedraagt zich anders zodra de daemon het uitvoert. De handmatige test slaagt, de dienstuitvoering mislukt, en de logregel noemt alleen de ontbrekende naam.

Python legt de locatie van het script bloot als __file__, en dat is wat verankering mogelijk maakt. Path(__file__).resolve().parent / "policy.json" bouwt een pad uit het bestand in plaats van uit het proces. Die ene regel verwijdert de afhankelijkheid van de werkmap zonder iets aan de rechten te veranderen.

Veranker het pad bewust en controleer dan wat resolve doet

resolve() volgt symbolische koppelingen, dus een installatie die de hook op zijn plek koppelt, verankert op het doel van de koppeling, niet op de map die de koppeling bevat. Dat is meestal wat u wilt voor een geversioneerde uitrol, en het is verkeerd voor een indeling die gegevens naast de symbolische koppeling verwacht. Bepaal wat de uitrol bedoelt, en schrijf de code daarnaar in plaats van het verschil in productie te ontdekken. Path(__file__).parent zonder resolve() behoudt de eigen map van de koppeling.

Als de gegevens bij de instantie horen en niet bij het programma, neem dan een absoluut pad uit de configuratie. Een locatie hard coderen koppelt de hook aan één hostindeling.

Doorloop vier grenzen in volgorde

Begin bij de werkmap: vergelijk de WorkingDirectory van de unit, de optie cd van OpenVPN en elke wrapper die vóór exec van map wisselt. Bevestig daarna de opgeloste locatie, want een bestand met een vergelijkbare naam in een andere uitrol kan de zoekactie beantwoorden en de fout verbergen. Daarna komt de kijk op het bestandssysteem: een chroot of een mount-naamruimte van de dienst kan een absoluut hostpad gewoon afwezig maken. Ten slotte de toegangsidentiteit, wat een vraag is die losstaat van zichtbaarheid.

ProtectHome en PrivateTmp verbergen verschillende locaties, en geen van beide verschijnt in een maplijst die van de host is genomen. Een pad dat voor root in een shell bestaat, kan binnen de naamruimte van de unit onzichtbaar zijn, en daarom bewijst het testen van dezelfde opdracht buiten de dienst zo weinig.

Herstel de zoekactie zonder de dienst te verbreden

Het verankeren van het pad lost alleen de eerste grens op. Het legt geen map bloot die de dienst verbergt, en het geeft een onbevoorrecht account geen toegang tot een bestand dat alleen voor root is. Het verhogen van script-security verandert welke scripts OpenVPN uitvoert; het heeft geen effect op waar een relatieve naam wordt opgelost. De werkmap voor de hele dienst wijzigen is breder dan het probleem, omdat elk ander relatief certificaat-, log- of hulppad meeverhuist.

Geef de voorkeur aan de smalle correctie: een deterministisch pad in het script, een expliciete configuratiewaarde voor instantiegegevens en bestandseigendom dat past bij het account waaronder de hook werkelijk draait.

Leg bewijs vast dat de grens benoemt

Een bruikbaar foutrapport bevat drie dingen: het exacte pad dat de hook probeerde, de omgeving die het opleverde, en welke grens weigerde. Druk het opgeloste pad en de uitzondering af zonder de inhoud van het bestand te storten. Dat drietal scheidt een verkeerde verankering van een verborgen mount en van een rechtenweigering, die drie verschillende correcties zijn.

De bewering dat root het bestand vanaf een terminal kan lezen, beantwoordt een van die vragen en geen van de andere. Test in plaats daarvan vanuit de eigen context van de dienst.