PrivateTmp: de hook schreef het bestand – waar is het gebleven?

Hooks melden succes, en hetzelfde pad ziet er vanuit een shell nog steeds leeg uit. Beide uitspraken kunnen tegelijk waar zijn, omdat een systemd-service in zijn eigen mount-naamruimte kan leven met een privé tijdelijke map. Als dat eenmaal begrepen is, wordt de interessante vraag of het schrijven überhaupt is gelukt.

Twee tijdelijke mappen, één pad

De isolatie-instelling geeft de unit een privébeeld van de tijdelijke mappen in plaats van ze alleen-lezen te maken. Processen buiten de unit kunnen niet zien wat hij daar schrijft, en alles wat hij achterlaat wordt weggegooid wanneer de unit stopt. Een pad dat de hook afdrukt en een pad dat vanuit een shell wordt gecontroleerd, kunnen dus verschillende objecten met dezelfde naam aanduiden.

Dat is een zichtbaarheidsprobleem, en het lijkt op een probleem met gegevensverlies. Er is niets verwijderd, omdat het bestand simpelweg in een naamruimte staat waar de shell geen lid van is. Hetzelfde commando gedraagt zich anders wanneer het binnen de unit wordt uitgevoerd, en dat is de observatie die het geschil meestal beslecht. Lees de instellingen van de unit voordat je iets over het schrijven concludeert.

Scheid onzichtbaar van onschrijfbaar

Een geslaagde schrijfactie en een mislukte open leveren verschillend bewijs, en dat verschil bepaalt de reparatie. Als de hook zegt dat het bestand is aangemaakt maar een externe lezer het niet vindt, heb je een naamruimtevraag. Als de hook een permissiefout of een mislukte open meldt, is het bestand nooit geschreven en helpt geen enkele wijziging van de naamruimte.

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

Het pad via de procesroot toont het eigen bestandssysteembeeld van de service, afhankelijk van permissiecontroles op dat proces zolang het nog draait. Lees het journaal van de unit in dezelfde sessie, want een schrijffout en een ontbrekend bestand worden gemakkelijk verward zodra iemand de oorzaak al heeft vastgesteld.

Geef gedeelde gegevens een expliciete locatie

Gegevens die alleen de service nodig heeft, horen in zijn privé tijdelijke map. Gegevens die een ander proces moet lezen hebben een pad nodig dat voor beide is gedefinieerd, met een vermelde eigenaar, modus en vervaldatum. Bepaal welke van de twee je hebt voordat je de unit bewerkt. De meeste van deze incidenten komen voort uit het behandelen van een privébestand als een gedeeld bestand.

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

Een runtime-map plaatst de map onder het runtime-gebied van het systeem, maakt hem aan voor de geconfigureerde gebruiker en groep van de unit en verwijdert hem wanneer de unit stopt. Voeg hem toe via een drop-in zodat de unit van het pakket intact blijft, herlaad daarna de beheerder en herstart die instantie, met de aanvaarding dat de clients opnieuw verbinding maken.

Behoud elke runtime-map die de geïnstalleerde unit al vereist. De lijst vervangen in plaats van aanvullen is een veelvoorkomende manier om een ongerelateerde functie te breken die niemand met de wijziging verbindt.

Twee privilegelagen kunnen het oneens zijn

De servicemanager maakt de map aan voor de geconfigureerde gebruiker van de unit, terwijl de VPN-daemon apart naar zijn eigen account kan zakken voordat hij een verbindingshook uitvoert. Dat zijn verschillende lagen, en ze kunnen verschillende identiteiten noemen.

Een map in eigendom van root met een beperkende modus is volledig zichtbaar voor een daemon die al privileges heeft opgegeven, en toch onschrijfbaar voor hem. De fout wordt dan gelezen als een permissieprobleem, hoewel het pad precies bestaat waar je het verwachtte. Vergelijk de eigenaar van de map met de identiteit die de hook meldt. Wanneer ze verschillen, was de modus nooit de vraag.

Controleer de identiteit waaronder de hook werkelijk draait voordat je het eigendom wijzigt. Het wijzigen van de uitvoeringsgebruiker van de service om een map te repareren kan apparaattoegang en netwerkprivileges elders veranderen, wat een hoge prijs is voor een klein probleem.

Verifieer de hele overdracht

Bevestig vier dingen tegelijk: de hook schrijft onder zijn echte identiteit, de bedoelde lezer kan het bestand gebruiken, ongerelateerde gebruikers kunnen dat niet, en het stoppen van de unit ruimt op zoals ontworpen. Dat een bestand verschijnt in de gedeelde tijdelijke map van de host is geen vereiste, en het is meestal een teken dat de uitwisseling nooit een eigen pad kreeg. Test de lezer na een herstart, niet alleen tijdens de eerste run. Opruimgedrag is deel van het ontwerp, dus observeer het in plaats van het aan te nemen.

Blijvende toestand hoort op een plek met een overeenkomstige levensduur, omdat een runtime-map bedoeld is om te verdwijnen. Kies de locatie op levensduur in plaats van op gemak. Die gewoonte voorkomt de volgende versie van hetzelfde onderzoek.