PrivateTmp: isinulat ng hook ang file, pero saan ito napunta?

Nagsusulat ng tagumpay ang mga hook, at ang parehong landas ay mukhang walang laman pa rin mula sa isang shell. Puwedeng totoo ang dalawang pahayag nang sabay, dahil ang isang serbisyo ng systemd ay maaaring tumira sa sarili nitong mount namespace na may pribadong pansamantalang direktoryo. Kapag naunawaan iyon, ang kawili-wiling tanong ay kung nagtagumpay ba ang pagsulat.

Dalawang pansamantalang direktoryo, isang landas

Binibigyan ng setting ng paghihiwalay ang unit ng pribadong tanawin ng mga pansamantalang direktoryo sa halip na gawin silang basahin lamang. Hindi nakikita ng mga proseso sa labas ng unit ang isinusulat nito doon, at anumang iniiwan nito ay itinatapon kapag huminto ang unit. Kaya ang landas na inilimbag ng hook at ang landas na sinuri mula sa shell ay maaaring tumukoy sa magkaibang bagay na may parehong pangalan.

Ito ay problema sa pagiging nakikita, at mukhang problema sa pagkawala ng data. Walang nabura, dahil ang file ay nasa namespace na hindi kasapi ang shell. Ang parehong utos ay iba ang kilos kapag pinatakbo sa loob ng unit, at iyon ang obserbasyong kadalasang nagtatapos sa pagtatalo. Basahin ang mga setting ng unit bago magpasya tungkol sa pagsulat.

Paghiwalayin ang hindi nakikita sa hindi maisusulat

Ang matagumpay na pagsulat at nabigong pagbukas ay nagbibigay ng magkaibang ebidensya, at ang pagkakaibang iyon ang nagpapasya sa pagkukumpuni. Kung sinasabi ng hook na nalikha ang file pero hindi ito makita ng panlabas na mambabasa, may tanong ka tungkol sa namespace. Kung nag-uulat ang hook ng error sa pahintulot o nabigong pagbukas, hindi kailanman naisulat ang file at walang pagbabago sa namespace ang makakatulong.

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

Ipinapakita ng landas sa ugat ng proseso ang sariling tanawin ng serbisyo sa file system, napapailalim sa mga pagsusuri ng pahintulot sa prosesong iyon habang tumatakbo pa ito. Basahin ang journal ng unit sa parehong sesyon, dahil madaling mapagkamalan ang error sa pagsulat at ang nawawalang file kapag may nagpasya na ng dahilan.

Bigyan ng malinaw na lokasyon ang ibinahaging data

Ang data na kailangan lamang ng serbisyo ay nasa pribadong pansamantalang direktoryo nito. Ang data na kailangang basahin ng ibang proseso ay nangangailangan ng landas na tinukoy para sa dalawa, na may nakasaad na may-ari, mode at pagtatapos. Magpasya kung alin sa dalawang kaso ang mayroon ka bago i-edit ang unit. Karamihan sa mga insidenteng ito ay nagmumula sa pagtrato sa pribadong file bilang ibinabahagi.

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

Inilalagay ng runtime directory ang folder sa ilalim ng runtime area ng system, ginagawa ito para sa naka-configure na user at group ng unit, at tinatanggal ito kapag huminto ang unit. Idagdag ito sa pamamagitan ng drop-in upang manatiling buo ang unit ng package, pagkatapos i-reload ang manager at i-restart ang instance na iyon, tinatanggap na muling kokonekta ang mga kliyente nito.

Panatilihin ang anumang runtime directory na kailangan na ng naka-install na unit. Ang palitan ang listahan sa halip na magdagdag dito ay karaniwang paraan ng pagsira sa walang kaugnayang feature na walang nag-uugnay sa pagbabago.

Maaaring hindi magkasundo ang dalawang antas ng pribilehiyo

Ginagawa ng service manager ang direktoryo para sa naka-configure na user ng unit, habang ang VPN daemon ay maaaring hiwalay na bumaba sa sarili nitong account bago magpatakbo ng connection hook. Iba’t ibang antas ang mga ito, at maaari silang magpangalan ng magkaibang pagkakakilanlan.

Ang direktoryong pag-aari ng root na may mahigpit na mode ay ganap na nakikita ng daemon na sumuko na sa mga pribilehiyo, at hindi pa rin ito maisusulat nito. Ang error ay binabasa noon bilang problema sa pahintulot kahit na ang landas ay naroroon mismo sa inaasahan mo. Ihambing ang may-ari ng direktoryo sa pagkakakilanlang iniuulat ng hook. Kapag magkaiba sila, hindi kailanman naging tanong ang mode.

Suriin kung sa ilalim ng aling pagkakakilanlan talagang tumatakbo ang hook bago baguhin ang pagmamay-ari. Ang pagbabago ng gumaganang user ng serbisyo upang ayusin ang direktoryo ay maaaring magbago ng pag-access sa device at mga pribilehiyo sa network sa ibang lugar, na mataas na halaga para sa maliit na problema.

I-verify ang buong paghahatid

Kumpirmahin ang apat na bagay nang sabay: nagsusulat ang hook sa ilalim ng tunay nitong pagkakakilanlan, magagamit ng inaasahang mambabasa ang file, hindi magagawa ng walang kaugnayang user, at naglilinis ang paghinto ng unit ayon sa disenyo. Ang paglitaw ng file sa ibinahaging pansamantalang direktoryo ng host ay hindi kinakailangan, at kadalasan ito ay senyales na hindi kailanman nakakuha ng sariling landas ang palitan. Subukan ang mambabasa pagkatapos ng restart, hindi lamang sa unang pagtakbo. Ang kilos ng paglilinis ay bahagi ng disenyo, kaya obserbahan ito sa halip na ipalagay.

Ang permanenteng estado ay kabilang sa lugar na may tugmang habang-buhay, dahil ang runtime directory ay sadyang mawala. Piliin ang lokasyon ayon sa habang-buhay at hindi ayon sa kaginhawahan. Pinipigilan ng ugaling iyon ang susunod na bersyon ng parehong pagsisiyasat.