PrivateTmp: hookas įrašė failą, bet kur jis dingo?

Hookai praneša apie sėkmę, o tas pats kelias iš shell vis dar atrodo tuščias. Abu teiginiai gali būti teisingi vienu metu, nes systemd paslauga gali gyventi savo mount vardų erdvėje su privačiu laikinuoju katalogu. Kai tai suprantama, įdomus klausimas tampa tai, ar įrašymas apskritai pavyko.

Du laikinieji katalogai, vienas kelias

Izoliacijos nustatymas suteikia unitui privatų laikinųjų katalogų vaizdą, o ne padaro juos tik skaitomus. Procesai už unito ribų negali matyti, ką jis ten rašo, o viskas, ką jis palieka, išmetama, kai unitas sustoja. Todėl hooko atspausdintas kelias ir iš shell patikrintas kelias gali nurodyti skirtingus objektus tuo pačiu pavadinimu.

Tai matomumo problema, ir ji atrodo kaip duomenų praradimo problema. Niekas nebuvo ištrinta, nes failas tiesiog yra vardų erdvėje, kurios shell nėra narė. Ta pati komanda elgiasi kitaip, kai vykdoma unito viduje, ir būtent šis stebėjimas paprastai išsprendžia ginčą. Prieš darydami bet kokią išvadą apie įrašymą, perskaitykite unito nustatymus.

Atskirkite nematomą nuo neįrašomo

Sėkmingas įrašymas ir nepavykęs atidarymas duoda skirtingus įrodymus, ir šis skirtumas nulemia taisymą. Jei hookas sako, kad failas sukurtas, bet išorinis skaitytojas jo neranda, turite vardų erdvės klausimą. Jei hookas praneša apie leidimų klaidą arba nepavykusį atidarymą, failas niekada nebuvo įrašytas ir joks vardų erdvės pakeitimas nepadės.

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

Kelias per proceso šaknį atskleidžia paslaugos pačios failų sistemos vaizdą, priklausomai nuo leidimų patikrų tam procesui, kol jis dar veikia. Skaitykite unito žurnalą toje pačioje sesijoje, nes įrašymo klaida ir trūkstamas failas lengvai supainiojami, kai kas nors jau nusprendė priežastį.

Suteikite bendriems duomenims aiškią vietą

Duomenys, kurių reikia tik paslaugai, priklauso jos privačiam laikinajam katalogui. Duomenys, kuriuos turi skaityti kitas procesas, reikalauja abiem apibrėžto kelio su nurodytu savininku, režimu ir galiojimo laiku. Nuspręskite, kuris iš dviejų atvejų yra jūsų, prieš redaguodami unitą. Dauguma šių incidentų kyla dėl to, kad privatus failas traktuojamas kaip bendras.

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

Vykdymo katalogas įdeda aplanką po sistemos vykdymo sritimi, sukuria jį unito sukonfigūruotam naudotojui ir grupei ir pašalina jį, kai unitas sustoja. Pridėkite jį per drop-in, kad paketo unitas liktų nepakitęs, tada iš naujo įkelkite valdytoją ir paleiskite tą egzempliorių iš naujo, priimdami, kad jo klientai vėl prisijungs.

Išsaugokite bet kurį vykdymo katalogą, kurio jau reikalauja įdiegtas unitas. Sąrašo pakeitimas, o ne papildymas, yra įprastas būdas sugadinti nesusijusią funkciją, kurios niekas nesusieja su pakeitimu.

Du privilegijų sluoksniai gali nesutarti

Paslaugų valdytojas sukuria katalogą unito sukonfigūruotam naudotojui, o VPN demonas prieš vykdydamas ryšio hooką gali atskirai pereiti į savo paskyrą. Tai skirtingi sluoksniai, ir jie gali įvardyti skirtingas tapatybes.

Rootui priklausantis katalogas su ribojančiu režimu yra visiškai matomas demonui, kuris jau atsisakė privilegijų, ir vis tiek jam neįrašomas. Tada klaida skaitoma kaip leidimų problema, nors kelias egzistuoja tiksliai ten, kur tikėjotės. Palyginkite katalogo savininką su tapatybe, kurią praneša hookas. Kai jie skiriasi, režimas niekada nebuvo klausimas.

Prieš keisdami nuosavybę patikrinkite, kokia tapatybe hookas iš tikrųjų veikia. Paslaugos vykdymo naudotojo pakeitimas, norint sutaisyti katalogą, gali pakeisti įrenginių prieigą ir tinklo privilegijas kitur, o tai didelė kaina už mažą problemą.

Patikrinkite visą perdavimą

Vienu metu patvirtinkite keturis dalykus: hookas rašo savo tikraja tapatybe, numatytas skaitytojas gali naudoti failą, nesusiję naudotojai negali, o unito sustabdymas sutvarko taip, kaip suprojektuota. Failo atsiradimas bendrame laikinajame hosto kataloge nėra reikalavimas, ir tai dažniausiai ženklas, kad mainai taip ir negavo savo kelio. Išbandykite skaitytoją po perkrovimo, ne tik pirmojo vykdymo metu. Valymo elgsena yra dizaino dalis, todėl stebėkite ją, o ne darykite prielaidas.

Nuolatinė būsena priklauso vietai, kurios gyvavimo trukmė atitinka, nes vykdymo katalogas skirtas išnykti. Vietą rinkitės pagal gyvavimo trukmę, o ne pagal patogumą. Šis įprotis užkerta kelią kitai to paties tyrimo versijai.