PrivateTmp: die hook het die lêer geskryf – waar het dit heen gegaan?

Hooks rapporteer sukses, en dieselfde pad lyk steeds leeg vanuit ’n skulp. Albei stellings kan gelyk waar wees, want ’n systemd-diens kan in sy eie monteernaamruimte met ’n private tydelike gids woon. Sodra dit verstaan word, word die interessante vraag of die skryf hoegenaamd geslaag het.

Twee tydelike gidse, een pad

Die isolasie-instelling gee die eenheid ’n private blik op die tydelike gidse eerder as om hulle net-lees te maak. Prosesse buite die eenheid kan nie sien wat hy daar skryf nie, en enigiets wat hy agterlaat, word weggegooi wanneer die eenheid stop. ’n Pad wat deur die hook gedruk word en ’n pad wat vanuit ’n skulp nagegaan word, kan dus na verskillende objekte met dieselfde naam verwys.

Dit is ’n sigbaarheidsprobleem, en dit lyk soos ’n dataverliesprobleem. Niks is uitgevee nie, want die lêer is bloot in ’n naamruimte waarvan die skulp nie ’n lid is nie. Dieselfde opdrag gedra hom anders wanneer dit binne die eenheid uitgevoer word, en dit is die waarneming wat die argument gewoonlik besleg. Lees die eenheid se instellings voordat jy enige gevolgtrekking oor die skryf maak.

Skei onsigbaar van onskryfbaar

’n Suksesvolle skryf en ’n mislukte oopmaak lewer verskillende bewyse, en die onderskeid bepaal die herstel. As die hook sê die lêer is geskep maar ’n buite-leser kan dit nie vind nie, het jy ’n naamruimtevraag. As die hook ’n toestemmingsfout of ’n mislukte oopmaak rapporteer, is die lêer nooit geskryf nie en geen naamruimteverandering sal help nie.

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

Die proseswortel-pad ontbloot die diens se eie lêerstelselblik, onderhewig aan toestemmingskontroles op daardie proses terwyl dit nog loop. Lees die joernaal vir die eenheid in dieselfde sessie, want ’n skryffout en ’n ontbrekende lêer is maklik om te verwar sodra iemand reeds die oorsaak besluit het.

Gee gedeelde data ’n eksplisiete plek

Data wat net die diens nodig het, hoort in sy private tydelike gids. Data wat ’n ander proses moet lees, het ’n pad nodig wat vir albei gedefinieer is, met ’n verklaarde eienaar, ’n modus en ’n vervaldatum. Besluit watter van die twee jy het voordat jy die eenheid wysig. Die meeste van hierdie voorvalle kom daarvan dat ’n private lêer as ’n gedeelde een behandel word.

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

’n Looptydgids plaas die vouer onder die stelsel se looptydgebied, skep dit vir die eenheid se gekonfigureerde gebruiker en groep, en verwyder dit wanneer die eenheid stop. Voeg dit deur ’n drop-in by sodat die pakket se eenheid ongeskonde bly, herlaai dan die bestuurder en herbegin daardie instansie, met die aanvaarding dat sy kliënte sal weerkoppel.

Behou enige looptydgids wat die geïnstalleerde eenheid reeds vereis. Om die lys te vervang in plaas van dit aan te vul, is ’n algemene manier om ’n onverwante funksie te breek wat niemand met die verandering verbind nie.

Twee voorreglae kan verskil

Die diensbestuurder skep die gids vir die eenheid se gekonfigureerde gebruiker, terwyl die VPN-daemon afsonderlik na sy eie rekening kan terugval voordat hy ’n verbindingshaak uitvoer. Dit is verskillende lae, en hulle kan verskillende identiteite noem.

’n Gids wat deur root besit word met ’n beperkende modus is heeltemal sigbaar vir ’n daemon wat reeds voorregte laat vaar het, en steeds onskryfbaar daarvoor. Die fout lees dan as ’n toestemmingsprobleem al bestaan die pad presies waar jy verwag het. Vergelyk die gids se eienaar met die identiteit wat die hook rapporteer. Wanneer hulle verskil, was die modus nooit die vraag nie.

Kontroleer die identiteit waaronder die hook werklik loop voordat jy eienaarskap verander. Om die diens se uitvoergebruiker te verander om ’n gids reg te maak, kan toesteltoegang en netwerkvoorregte elders verander, wat ’n groot prys vir ’n klein probleem is.

Verifieer die hele oorhandiging

Bevestig vier dinge tegelyk: die hook skryf onder sy werklike identiteit, die beoogde leser kan die lêer verbruik, onverwante gebruikers kan nie, en die stop van die eenheid ruim op soos ontwerp. ’n Lêer wat in die gasheer se gedeelde tydelike gids verskyn, is nie ’n vereiste nie, en dit is gewoonlik ’n teken dat die uitruiling nooit sy eie pad gekry het nie. Toets die leser ná ’n herbegin, nie net tydens die eerste loop nie. Opruimgedrag is deel van die ontwerp, so neem dit waar eerder as om dit te aanvaar.

Volgehoue toestand hoort êrens met ’n ooreenstemmende lewensduur, want ’n looptydgids is bedoel om te verdwyn. Kies die plek volgens lewensduur eerder as volgens gerief. Daardie gewoonte voorkom die volgende weergawe van dieselfde ondersoek.