PrivateTmp: hooken skrev filen – hvor ble den av?

Hooker rapporterer suksess, og den samme stien ser fortsatt tom ut fra en shell. Begge utsagnene kan være sanne samtidig, fordi en systemd-tjeneste kan leve i sitt eget mount-navnerom med en privat midlertidig mappe. Når det er forstått, blir det interessante spørsmålet om skrivingen i det hele tatt lyktes.

To midlertidige mapper, én sti

Isolasjonsinnstillingen gir enheten et privat syn på de midlertidige mappene i stedet for å gjøre dem skrivebeskyttet. Prosesser utenfor enheten kan ikke se hva den skriver der, og alt den etterlater seg, kastes når enheten stopper. En sti som hooken skriver ut, og en sti som kontrolleres fra en shell, kan derfor peke på forskjellige objekter med samme navn.

Dette er et synlighetsproblem, og det ser ut som et datatapsproblem. Ingenting ble slettet, fordi filen rett og slett ligger i et navnerom som shellen ikke er medlem av. Den samme kommandoen oppfører seg annerledes når den kjøres inne i enheten, og det er den observasjonen som vanligvis avgjør diskusjonen. Les innstillingene til enheten før du konkluderer noe om skrivingen.

Skill usynlig fra uskrivbar

En vellykket skriving og en mislykket åpning gir forskjellige bevis, og forskjellen avgjør reparasjonen. Hvis hooken sier at filen ble opprettet, men en ekstern leser ikke finner den, har du et navneromsspørsmål. Hvis hooken rapporterer en tillatelsesfeil eller en mislykket åpning, ble filen aldri skrevet, og ingen endring av navnerommet vil hjelpe.

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

Stien via prosessroten viser tjenestens eget filsystemsyn, underlagt tillatelseskontroller på den prosessen mens den fortsatt kjører. Les journalen til enheten i samme økt, fordi en skrivefeil og en manglende fil lett forveksles når noen først har bestemt årsaken.

Gi delte data en eksplisitt plassering

Data som bare tjenesten trenger, hører i dens private midlertidige mappe. Data som en annen prosess må lese, trenger en sti definert for begge, med oppgitt eier, modus og utløp. Bestem hvilken av de to du har, før du redigerer enheten. De fleste av disse hendelsene kommer av å behandle en privat fil som en delt.

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

En runtime-mappe plasserer mappen under systemets runtime-område, oppretter den for enhetens konfigurerte bruker og gruppe og fjerner den når enheten stopper. Legg den til via en drop-in slik at pakkens enhet forblir intakt, last deretter inn administratoren på nytt og start den instansen på nytt, med aksept for at klientene dens kobles til igjen.

Behold enhver runtime-mappe som den installerte enheten allerede krever. Å erstatte listen i stedet for å legge til i den er en vanlig måte å ødelegge en urelatert funksjon som ingen forbinder med endringen.

To privilegielag kan være uenige

Tjenesteadministratoren oppretter mappen for enhetens konfigurerte bruker, mens VPN-demonen separat kan gå ned til sin egen konto før den kjører en tilkoblingshook. Det er forskjellige lag, og de kan navngi forskjellige identiteter.

En root-eid mappe med restriktiv modus er fullt synlig for en demon som allerede har gitt slipp på privilegier, og fortsatt uskrivbar for den. Feilen leses da som et tillatelsesproblem selv om stien finnes nøyaktig der du forventet. Sammenlign mappens eier med identiteten hooken rapporterer. Når de er forskjellige, var modusen aldri spørsmålet.

Kontroller identiteten hooken faktisk kjører som, før du endrer eierskap. Å endre tjenestens kjørende bruker for å rette en mappe kan endre enhetstilgang og nettverksprivilegier andre steder, noe som er en høy pris for et lite problem.

Verifiser hele overleveringen

Bekreft fire ting på én gang: hooken skriver under sin virkelige identitet, den tiltenkte leseren kan forbruke filen, urelaterte brukere kan ikke, og stopp av enheten rydder opp som designet. At en fil dukker opp i vertens delte midlertidige mappe er ikke et krav, og det er vanligvis et tegn på at utvekslingen aldri fikk sin egen sti. Test leseren etter en omstart, ikke bare under den første kjøringen. Oppryddingsatferd er en del av designet, så observer den i stedet for å anta den.

Vedvarende tilstand hører hjemme et sted med tilsvarende levetid, siden en runtime-mappe er ment å forsvinne. Velg plasseringen etter levetid i stedet for etter bekvemmelighet. Den vanen forhindrer neste versjon av nettopp denne undersøkelsen.