PrivateTmp: hooket skrev filen – hvor blev den af?

Hookene rapporterer succes, og den samme sti ser stadig tom ud fra en shell. Begge udsagn kan være sande på én gang, fordi en systemd-tjeneste kan leve i sit eget mount-navnerum med en privat midlertidig mappe. Når det er forstået, bliver det interessante spørgsmål, om skrivningen overhovedet lykkedes.

To midlertidige mapper, én sti

Isoleringsindstillingen giver unit’en et privat syn på de midlertidige mapper i stedet for at gøre dem skrivebeskyttede. Processer uden for unit’en kan ikke se, hvad den skriver der, og alt, hvad den efterlader, kasseres, når unit’en stopper. En sti, som hooket udskriver, og en sti, som kontrolleres fra en shell, kan derfor pege på forskellige objekter med samme navn.

Det er et synlighedsproblem, og det ligner et datatabproblem. Intet er slettet, fordi filen simpelthen er i et navnerum, som shellen ikke er medlem af. Den samme kommando opfører sig anderledes, når den køres inde i unit’en, og det er den observation, der normalt afgør diskussionen. Læs unit’ens indstillinger, før du konkluderer noget om skrivningen.

Adskil usynligt fra uskrivbart

En vellykket skrivning og en mislykket åbning giver forskellige beviser, og forskellen afgør reparationen. Hvis hooket siger, at filen blev oprettet, men en ekstern læser ikke kan finde den, har du et navnerumsspørgsmål. Hvis hooket rapporterer en tilladelsesfejl eller en mislykket åbning, blev filen aldrig skrevet, og ingen ændring af navnerummet vil hjælpe.

systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-state

Procesrod-stien afslører tjenestens eget filsystemsyn, underlagt tilladelseskontroller på den proces, mens den stadig kører. Læs unit’ens journal i samme session, fordi en skrivefejl og en manglende fil let forveksles, når nogen først har besluttet årsagen.

Giv delte data en eksplicit placering

Data, som kun tjenesten har brug for, hører i dens private midlertidige mappe. Data, som en anden proces skal læse, kræver en sti, der er defineret for begge, med angivet ejer, tilstand og udløb. Beslut, hvilken af de to du har, før du redigerer unit’en. De fleste af disse hændelser kommer af at behandle en privat fil som en delt.

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

En runtime-mappe placerer mappen under systemets runtime-område, opretter den for unit’ens konfigurerede bruger og gruppe og fjerner den, når unit’en stopper. Tilføj den via en drop-in, så pakkens unit forbliver intakt, genindlæs derefter manageren, og genstart den instans, idet du accepterer, at dens klienter genopretter forbindelsen.

Behold enhver runtime-mappe, som den installerede unit allerede kræver. At erstatte listen i stedet for at føje til den er en almindelig måde at ødelægge en urelateret funktion, som ingen forbinder med ændringen.

To privilegielag kan være uenige

Tjenestemanageren opretter mappen for unit’ens konfigurerede bruger, mens VPN-dæmonen separat kan skifte til sin egen konto, før den kører et forbindelseshook. Det er forskellige lag, og de kan angive forskellige identiteter.

En root-ejet mappe med en restriktiv tilstand er fuldt synlig for en dæmon, der allerede har opgivet privilegier, og stadig uskrivbar for den. Fejlen læses så som et tilladelsesproblem, selv om stien findes præcis, hvor du forventede. Sammenlign mappens ejer med den identitet, hooket rapporterer. Når de er forskellige, var tilstanden aldrig spørgsmålet.

Kontroller den identitet, hooket reelt kører som, før du ændrer ejerskab. At ændre tjenestens kørende bruger for at rette en mappe kan ændre enhedsadgang og netværksprivilegier andre steder, hvilket er en høj pris for et lille problem.

Bekræft hele overdragelsen

Bekræft fire ting på én gang: hooket skriver under sin virkelige identitet, den tilsigtede læser kan forbruge filen, urelaterede brugere kan ikke, og stop af unit’en rydder op som designet. At en fil dukker op i værtens delte midlertidige mappe er ikke et krav, og det er normalt et tegn på, at udvekslingen aldrig fik sin egen sti. Test læseren efter en genstart, ikke kun under den første kørsel. Oprydningsadfærd er en del af designet, så observer den i stedet for at antage den.

Vedvarende tilstand hører et sted med en tilsvarende levetid, da en runtime-mappe er beregnet til at forsvinde. Vælg placeringen efter levetid i stedet for efter bekvemmelighed. Den vane forhindrer den næste version af netop denne undersøgelse.