Hvorfor et OpenVPN-hook ikke kan finde filen ved siden af sit script

Hooks, der kører uden fejl og alligevel rapporterer en manglende fil, kigger normalt det forkerte sted, ikke fejler i deres arbejde. Relative stier i et script opløses mod processens arbejdsmappe, og en tjeneste starter med en arbejdsmappe, du ikke har valgt. Filen ved siden af scriptet og filen, som processen åbner, er kun det samme, når noget forankrer dem. Det gab forklarer en stor del af hook-fejl, som fejlagtigt læses som tilladelsesproblemer.

Kontroller stien før tilladelserne, fordi en tilladelsesfejl på den forkerte fil stadig er den forkerte fil.

En relativ sti opløses mod processen, ikke mod filen

Når et script kalder open("policy.json"), opløser kernen navnet mod processens aktuelle arbejdsmappe. Intet ved scriptets egen placering deltager i den opslag. OpenVPN starter hooks fra en mappe, den selv vælger, og indstillingen cd kan ændre den, så et script, der er testet i hånden fra sin egen mappe, opfører sig anderledes, når daemonen kører det. Den manuelle test består, tjenestekørslen fejler, og loglinjen nævner kun det manglende navn.

Python eksponerer scriptets placering som __file__, og det er det, der gør forankring mulig. Path(__file__).resolve().parent / "policy.json" bygger en sti ud fra filen i stedet for processen. Den ene linje fjerner afhængigheden af arbejdsmappen uden at ændre noget ved privilegier.

Forankr stien med vilje, og kontroller derefter, hvad resolve gør

resolve() følger symbolske links, så en installation, der linker hooket på plads, forankrer ved linkets mål, ikke ved mappen, der indeholder linket. Det er normalt det, du vil have til en versioneret udrulning, og det er forkert for et layout, der forventer data ved siden af det symbolske link. Beslut, hvad udrulningen mener, og skriv koden så den passer, i stedet for at opdage forskellen i produktion. Path(__file__).parent uden resolve() bevarer linkets egen mappe.

Hvis dataene tilhører instansen og ikke programmet, skal du tage en absolut sti fra konfigurationen. Hårdkodning af en placering binder hooket til ét værtslayout.

Gå fire grænser igennem i rækkefølge

Start med arbejdsmappen: sammenlign enhedens WorkingDirectory, OpenVPNs cd indstilling og enhver indpakning, der skifter mappe før exec. Bekræft derefter den opløste placering, fordi en fil med samme navn i en anden udrulning kan svare på opslaget og skjule fejlen. Derefter kommer filsystemvisningen: en chroot eller en mount-navnerum for tjenesten kan gøre en absolut værtssti ganske enkelt fraværende. Sidst er adgangsidentiteten, som er et spørgsmål adskilt fra synlighed.

ProtectHome og PrivateTmp skjuler forskellige placeringer, og ingen af dem vises i en mappeliste taget fra værten. En sti, der findes for root i en shell, kan være usynlig inde i enhedens navnerum, og derfor beviser test af den samme kommando uden for tjenesten så lidt.

Ret opslaget uden at udvide tjenesten

Forankring af stien løser kun den første grænse. Det afslører ikke en mappe, tjenesten skjuler, og det giver ikke en uprivilegeret konto adgang til en fil, kun root må læse. At øge script-security ændrer, hvilke scripts OpenVPN vil køre; det har ingen effekt på, hvor et relativt navn opløses. At ændre arbejdsmappen for hele tjenesten er bredere end problemet, fordi enhver anden relativ certifikat-, log- eller hjælpesti flytter med.

Foretræk den snævre rettelse: en deterministisk sti i scriptet, en eksplicit konfigurationsværdi til instansdata og fil-ejerskab, der matcher den konto, hooket faktisk kører som.

Registrer bevis, der navngiver grænsen

En brugbar fejlrapport indeholder tre ting: den præcise sti, hooket forsøgte, det miljø, der frembragte den, og hvilken grænse der afviste. Udskriv den opløste sti og undtagelsen uden at dumpe filens indhold. Den tredobbelte oplysning adskiller en forkert forankring fra en skjult mount og fra en nægtet tilladelse, som er tre forskellige rettelser.

Påstanden om, at root kan læse filen fra en terminal, besvarer et af de spørgsmål og ingen af de andre. Test i stedet fra tjenestens eget kontekst.