Log roste, ale nelze ho znovu vytvořit: zkontrolujte ACL adresáře

Log, který neustále roste, přestane růst ve chvíli, kdy jej něco znovu vytvoří, a chyba říká permission denied. Lákavý závěr je, že samotný soubor logu potřebuje více oprávnění, ale soubor už může být zapisovatelný stejným účtem. Připojování k existujícímu jménu a vytvoření nového jsou různé kontroly a pouze ta druhá se ptá adresáře.

Připojení a vytvoření jsou různé kontroly

Otevření existujícího souboru pro připojení vyžaduje právo zápisu na tento soubor a právo prohledávání ve všech adresářích na jeho cestě. Vytvoření souboru vyžaduje zápis a prohledávání v obsahujícím adresáři, protože operace do něj přidává jméno. Nahrazení souboru přejmenováním se dotýká obou adresářů i jejich pravidel sticky bitu.

Již otevřený deskriptor přidává čtvrtý případ. Proces může držet zapisovatelný handle otevřený předtím, než se vzdal oprávnění, a přesto nedokázat znovu otevřít stejnou cestu pod svou pozdější identitou. Úspěšná připojení a neúspěšné vytvoření mohou platit zároveň, ve stejný okamžik, pro tentýž proces.

Výchozí ACL se dědí, neudělují

Záznam začínající výchozím prefixem popisuje, co nové objekty dědí z adresáře. Adresáři samotnému nic neuděluje a neopravuje ACL souboru, který už existuje.

namei -l /var/log/openvpn/server.log
getfacl -p /var/log/openvpn
getfacl -p /var/log/openvpn/server.log

Čtěte přístupové záznamy odděleně od výchozích a čtěte masku. Pojmenovaný záznam, který vypisuje plná práva, může být stále omezen maskou, a proto je efektivní komentář důležitější než písmena na prvním řádku.

Používejte rozřešenou cestu, ne cestu z konfigurace. Symlink, přípojný bod nebo rotovaný adresář mohou umístit skutečný soubor tam, kam udělené oprávnění nikdy nedosáhne. Nejprve projděte cestu nástrojem pro jména, pak porovnejte každou úroveň s dotčeným účtem. Hádání na nejvyšším adresáři je způsob, jak oprava skončí o úroveň výš.

Zjistěte, kdo v tu chvíli zapisuje

Než cokoli změníte, zkontrolujte jednotku služby, její drop-in soubory a vlastní nastavení účtu démona. Proces, který připojuje, a proces, který znovu vytváří, mohou být různé: pomocník rotace, zapisovač stavu a webový čtenář málokdy sdílejí identitu.

Testovací spuštění z root shellu nereprodukuje omezenou službu, a uspěje, zatímco služba dál selhává. Reprodukujte selhávající operaci pod stejnou jednotkou, se stejným účtem a stejným nastavením sandboxu. Pokud nemůžete, spusťte jednotku s dočasným shellem a zkontrolujte identitu, kterou hlásí. Cokoli jiného měří váš terminál, ne službu.

Je-li vytvoření opravdu nutné, dejte zapisovateli přístup k vyhrazenému adresáři logů a čtecí přístup pro konzumenty držte odděleně. Udělat sdílený účet nebo celý strom aplikace zapisovatelným, aby stačilo jedno volání logu, vyměňuje malý problém za velký.

Rotujte, aniž byste to vrátili

Kdo soubor znovu vytvoří, rozhoduje o jeho vlastníkovi a režimu pro další cyklus, proto sluďte opravu s konfigurací rotace. Náhrada vytvořená pod jiným účtem nebo s novým ACL vrátí selhání po úspěšné opravě.

Nastavte režim a skupinu při vytvoření, ne potom, a ověřujte další rotaci, ne další připojení. Připojení jen opakuje test, který už prošel. Pokud nástroj rotace nabízí nastavení režimu vytvoření, použijte je místo chmod po vytvoření. Mezera mezi vytvořením a chmod je přesně ta chvíle, kdy další zápis může selhat.

Když oříznutí stejně selže, přestaňte přidávat oprávnění

Selhání oříznutí souboru, do kterého můžete psát, se oprávněními adresáře nevysvětluje a přidání dalších nepomůže. Podívejte se místo toho na atributy a omezení: atribut append-only povoluje zápis jen v režimu připojení a připojení jen pro čtení nebo sandbox služby mohou odmítnout operaci, kterou ACL povoluje.

Zkontrolujte omezení souborového systému jednotky a možnosti připojení cesty, potom reprodukujte přesně tu operaci, která selhala. Rozšíření oprávnění, na které se nikdy neptalo, jen skrývá, které omezení bylo skutečné. Odebírejte jedno omezení po druhém v jednorázové jednotce a před trvalou změnou je vraťte.