PrivateTmp: hook zapisał plik, ale gdzie on się podział?

Hooki zgłaszają sukces, a ta sama ścieżka nadal wygląda na pustą z poziomu powłoki. Oba stwierdzenia mogą być prawdziwe jednocześnie, ponieważ usługa systemd może żyć we własnej przestrzeni nazw montowania z prywatnym katalogiem tymczasowym. Gdy to zrozumiemy, ciekawym pytaniem staje się, czy zapis w ogóle się udał.

Dwa katalogi tymczasowe, jedna ścieżka

Ustawienie izolacji daje jednostce prywatny widok katalogów tymczasowych, zamiast czynić je tylko do odczytu. Procesy spoza jednostki nie widzą, co tam zapisuje, a wszystko, co zostawi, jest odrzucane, gdy jednostka się zatrzyma. Ścieżka wypisana przez hook i ścieżka sprawdzona z powłoki mogą więc wskazywać różne obiekty o tej samej nazwie.

To problem widoczności, a wygląda jak problem utraty danych. Nic nie zostało usunięte, bo plik po prostu znajduje się w przestrzeni nazw, której powłoka nie jest członkiem. To samo polecenie zachowuje się inaczej, gdy jest uruchamiane wewnątrz jednostki, i właśnie ta obserwacja zwykle rozstrzyga spór. Przeczytaj ustawienia jednostki, zanim wyciągniesz jakikolwiek wniosek o zapisie.

Oddziel niewidoczne od niezapisywalnego

Udany zapis i nieudane otwarcie dają różne dowody, a ta różnica decyduje o naprawie. Jeśli hook mówi, że plik powstał, ale zewnętrzny czytelnik go nie znajduje, masz pytanie o przestrzeń nazw. Jeśli hook zgłasza błąd uprawnień lub nieudane otwarcie, plik nigdy nie został zapisany i żadna zmiana przestrzeni nazw nie pomoże.

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

Ścieżka przez korzeń procesu pokazuje własny widok systemu plików usługi, zależny od kontroli uprawnień na tym procesie, dopóki jeszcze działa. Czytaj dziennik jednostki w tej samej sesji, bo błąd zapisu i brakujący plik łatwo pomylić, gdy ktoś już zdecydował o przyczynie.

Daj współdzielonym danym wyraźne miejsce

Dane, których potrzebuje tylko usługa, należą do jej prywatnego katalogu tymczasowego. Dane, które musi czytać inny proces, wymagają ścieżki zdefiniowanej dla obu, z podanym właścicielem, trybem i terminem ważności. Zdecyduj, który z dwóch przypadków masz, zanim edytujesz jednostkę. Większość takich incydentów bierze się z traktowania prywatnego pliku jak współdzielonego.

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

Katalog czasu działania umieszcza folder w obszarze czasu działania systemu, tworzy go dla skonfigurowanego użytkownika i grupy jednostki oraz usuwa go, gdy jednostka się zatrzyma. Dodaj go przez drop-in, aby jednostka pakietu pozostała nienaruszona, potem przeładuj menedżer i uruchom ponownie tę instancję, akceptując, że jej klienci połączą się ponownie.

Zachowaj każdy katalog czasu działania, którego zainstalowana jednostka już wymaga. Zastępowanie listy zamiast dodawania do niej to częsty sposób psucia niepowiązanej funkcji, której nikt nie łączy ze zmianą.

Dwie warstwy uprawnień mogą się nie zgadzać

Menedżer usług tworzy katalog dla skonfigurowanego użytkownika jednostki, natomiast demon VPN może osobno zejść na własne konto przed uruchomieniem hooka połączenia. To różne warstwy i mogą wskazywać różne tożsamości.

Katalog należący do roota z restrykcyjnym trybem jest doskonale widoczny dla demona, który już zrzekł się uprawnień, a mimo to niezapisywalny dla niego. Błąd jest wtedy czytany jako problem uprawnień, choć ścieżka istnieje dokładnie tam, gdzie jej oczekiwałeś. Porównaj właściciela katalogu z tożsamością zgłaszaną przez hook. Gdy się różnią, tryb nigdy nie był pytaniem.

Sprawdź, jako kto hook naprawdę działa, zanim zmienisz własność. Zmiana użytkownika wykonawczego usługi, by naprawić katalog, może zmienić dostęp do urządzeń i uprawnienia sieciowe gdzie indziej, co jest wysoką ceną za mały problem.

Zweryfikuj całe przekazanie

Potwierdź cztery rzeczy naraz: hook zapisuje pod swoją prawdziwą tożsamością, zamierzony czytelnik może użyć pliku, niepowiązani użytkownicy nie mogą, a zatrzymanie jednostki sprząta zgodnie z projektem. Pojawienie się pliku we współdzielonym katalogu tymczasowym hosta nie jest wymogiem i zwykle oznacza, że wymiana nigdy nie dostała własnej ścieżki. Przetestuj czytelnika po restarcie, nie tylko podczas pierwszego uruchomienia. Zachowanie sprzątania jest częścią projektu, więc obserwuj je, zamiast zakładać.

Trwały stan należy do miejsca o pasującym czasie życia, ponieważ katalog czasu działania ma zniknąć. Wybierz lokalizację według czasu życia, a nie według wygody. Ten nawyk zapobiega następnej wersji tego samego śledztwa.