PrivateTmp: hooken skrev filen – vart tog den vägen?

Hooks rapporterar framgång, och samma sökväg ser fortfarande tom ut från ett shell. Båda påståendena kan vara sanna samtidigt, eftersom en systemd-tjänst kan leva i sitt eget mount-namnrum med en privat tillfällig katalog. När det är förstått blir den intressanta frågan om skrivningen ens lyckades.

Två tillfälliga kataloger, en sökväg

Isoleringsinställningen ger enheten en privat vy av de tillfälliga katalogerna i stället för att göra dem skrivskyddade. Processer utanför enheten kan inte se vad den skriver där, och allt den lämnar efter sig kastas när enheten stoppas. En sökväg som hooken skriver ut och en sökväg som kontrolleras från ett shell kan därför peka på olika objekt med samma namn.

Det är ett synlighetsproblem, och det ser ut som ett dataförlustproblem. Ingenting raderades, eftersom filen helt enkelt ligger i ett namnrum som shellen inte är medlem i. Samma kommando beter sig annorlunda när det körs inne i enheten, och det är den observationen som vanligtvis avgör diskussionen. Läs enhetens inställningar innan du drar någon slutsats om skrivningen.

Skilj osynligt från oskrivbart

En lyckad skrivning och en misslyckad öppning ger olika bevis, och skillnaden avgör reparationen. Om hooken säger att filen skapades men en extern läsare inte hittar den, har du en namnrumfråga. Om hooken rapporterar ett behörighetsfel eller en misslyckad öppning, skrevs filen aldrig och ingen ändring av namnrummet hjälper.

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

Sökvägen via processroten visar tjänstens egen filsystemsvy, beroende på behörighetskontroller på den processen så länge den fortfarande körs. Läs enhetens journal i samma session, eftersom ett skrivfel och en saknad fil lätt förväxlas när någon redan bestämt orsaken.

Ge delade data en tydlig plats

Data som bara tjänsten behöver hör hemma i dess privata tillfälliga katalog. Data som en annan process måste läsa behöver en sökväg definierad för båda, med angiven ägare, läge och utgång. Bestäm vilket av de två fallen du har innan du redigerar enheten. De flesta av dessa incidenter kommer av att en privat fil behandlas som delad.

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

En runtime-katalog placerar mappen under systemets runtime-område, skapar den för enhetens konfigurerade användare och grupp och tar bort den när enheten stoppas. Lägg till den via en drop-in så att paketets enhet förblir intakt, ladda sedan om hanteraren och starta om den instansen, med acceptans för att dess klienter återansluter.

Behåll varje runtime-katalog som den installerade enheten redan kräver. Att ersätta listan i stället för att lägga till i den är ett vanligt sätt att bryta en orelaterad funktion som ingen kopplar till ändringen.

Två privilegielager kan vara oense

Tjänstehanteraren skapar katalogen för enhetens konfigurerade användare, medan VPN-demonen separat kan kliva ned till sitt eget konto innan den kör en anslutningshook. Det är olika lager, och de kan namnge olika identiteter.

En rootägd katalog med restriktivt läge är fullt synlig för en demon som redan har avsagt sig privilegier, och ändå oskrivbar för den. Felet läses då som ett behörighetsproblem trots att sökvägen finns exakt där du förväntade dig. Jämför katalogens ägare med identiteten som hooken rapporterar. När de skiljer sig var läget aldrig frågan.

Kontrollera identiteten som hooken faktiskt körs som innan du ändrar ägandet. Att ändra tjänstens körande användare för att reparera en katalog kan ändra enhetsåtkomst och nätverksprivilegier på andra håll, vilket är ett högt pris för ett litet problem.

Verifiera hela överlämningen

Bekräfta fyra saker samtidigt: hooken skriver under sin verkliga identitet, den avsedda läsaren kan använda filen, orelaterade användare kan inte, och stopp av enheten städar som designat. Att en fil dyker upp i värdens delade tillfälliga katalog är inget krav, och det är oftast ett tecken på att utbytet aldrig fick en egen sökväg. Testa läsaren efter en omstart, inte bara under första körningen. Städningsbeteende är en del av designen, så observera det i stället för att anta det.

Beständigt tillstånd hör hemma på en plats med motsvarande livslängd, eftersom en runtime-katalog är avsedd att försvinna. Välj platsen efter livslängd i stället för efter bekvämlighet. Den vanan förhindrar nästa version av samma undersökning.