PrivateTmp: a hook megírta a fájlt, de hová tűnt?

A hookok sikert jelentenek, és ugyanaz az útvonal egy shellből nézve még mindig üresnek látszik. Mindkét állítás egyszerre is igaz lehet, mert egy systemd szolgáltatás a saját mount-névterében élhet privát ideiglenes könyvtárral. Ha ezt megértettük, az érdekes kérdés az lesz, hogy az írás egyáltalán sikerült-e.

Két ideiglenes könyvtár, egy útvonal

Az elkülönítési beállítás privát nézetet ad az unitnak az ideiglenes könyvtárakra ahelyett, hogy csak olvashatóvá tenné őket. Az uniton kívüli folyamatok nem látják, mit ír oda, és minden, amit maga után hagy, eldobódik, amikor az unit leáll. Ezért a hook által kiírt útvonal és a shellből ellenőrzött útvonal különböző, azonos nevű objektumokra utalhat.

Ez láthatósági probléma, és adatvesztési problémának tűnik. Semmi nem törlődött, mert a fájl egyszerűen egy névtérben van, amelynek a shell nem tagja. Ugyanaz a parancs másképp viselkedik az uniton belül futtatva, és általában ez a megfigyelés dönti el a vitát. Olvasd el az unit beállításait, mielőtt bármit megállapítasz az írásról.

Válaszd külön a láthatatlant az írhatatlantól

A sikeres írás és a sikertelen megnyitás eltérő bizonyítékot ad, és ez a különbség dönti el a javítást. Ha a hook azt mondja, hogy a fájl létrejött, de egy külső olvasó nem találja, névtérkérdésed van. Ha a hook engedélyhibát vagy sikertelen megnyitást jelent, a fájl soha nem íródott meg, és semmilyen névtérmódosítás nem segít.

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

A folyamat gyökérútvonala a szolgáltatás saját fájlrendszer-nézetét tárja fel, a folyamatra vonatkozó engedélyellenőrzések függvényében, amíg az még fut. Olvasd az unit naplóját ugyanabban a munkamenetben, mert az írási hiba és a hiányzó fájl könnyen összekeveredik, ha valaki már eldöntötte az okot.

Adj kifejezett helyet a megosztott adatoknak

Azok az adatok, amelyekre csak a szolgáltatásnak van szüksége, a privát ideiglenes könyvtárába tartoznak. Azok az adatok, amelyeket egy másik folyamatnak olvasnia kell, mindkettő számára meghatározott útvonalat igényelnek, megadott tulajdonossal, móddal és lejárattal. Döntsd el, melyik eset áll fenn, mielőtt szerkeszted az unitot. Ezek az esetek többnyire abból adódnak, hogy egy privát fájlt megosztottként kezelnek.

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

A futásidejű könyvtár a mappát a rendszer futásidejű területe alá helyezi, létrehozza az unit beállított felhasználója és csoportja számára, és eltávolítja, amikor az unit leáll. Egy drop-inon keresztül add hozzá, hogy a csomag unitja érintetlen maradjon, majd töltsd újra a kezelőt, és indítsd újra azt a példányt, elfogadva, hogy az ügyfelei újra csatlakoznak.

Tartsd meg minden futásidejű könyvtárat, amelyet a telepített unit már igényel. A lista lecserélése a hozzáadás helyett gyakori módja egy független funkció elrontásának, amelyet senki sem köt a változtatáshoz.

Két jogosultsági réteg eltérhet

A szolgáltatáskezelő létrehozza a könyvtárat az unit beállított felhasználója számára, míg a VPN-démon külön a saját fiókjára léphet, mielőtt kapcsolati hookot futtat. Ezek különböző rétegek, és különböző identitásokat nevezhetnek meg.

A root tulajdonában lévő, korlátozó módú könyvtár teljesen látható egy olyan démon számára, amely már lemondott a jogosultságairól, és mégis írhatatlan neki. A hiba ekkor engedélyproblémaként olvasható, pedig az útvonal pontosan ott létezik, ahol vártad. Hasonlítsd össze a könyvtár tulajdonosát a hook által jelentett identitással. Amikor eltérnek, a mód soha nem volt kérdés.

Ellenőrizd, milyen identitás alatt fut valójában a hook, mielőtt megváltoztatod a tulajdonjogot. A szolgáltatás futtatási felhasználójának megváltoztatása egy könyvtár javításához máshol módosíthatja az eszközhozzáférést és a hálózati jogosultságokat, ami nagy ár egy kis problémáért.

Ellenőrizd a teljes átadást

Négy dolgot egyszerre erősíts meg: a hook a valódi identitása alatt ír, a szánt olvasó fel tudja használni a fájlt, a nem kapcsolódó felhasználók nem tudják, és az unit leállítása a tervezett módon takarít. Az, hogy egy fájl megjelenik a gazdagép megosztott ideiglenes könyvtárában, nem követelmény, és általában annak a jele, hogy az átadás soha nem kapott saját útvonalat. Teszteld az olvasót újraindítás után, ne csak az első futáskor. A takarítási viselkedés a tervezés része, ezért figyeld meg, ahelyett hogy feltételeznéd.

A tartós állapot olyan helyre tartozik, amelynek élettartama illeszkedik, mert a futásidejű könyvtárnak el kell tűnnie. A helyet az élettartam szerint válaszd, nem a kényelem szerint. Ez a szokás megakadályozza ugyanennek a vizsgálatnak a következő változatát.