Loggen växer men kan inte återskapas: kontrollera katalogens ACL

En logg som fortsätter växa slutar växa i samma stund som något återskapar den, och felet säger att behörigheten nekades. Den frestande slutsatsen är att loggfilen själv behöver fler behörigheter, men filen kan redan vara skrivbar för samma konto. Att lägga till i ett befintligt namn och att skapa ett nytt namn är två olika kontroller, och bara den andra frågar katalogen.

Att lägga till och att skapa är olika kontroller

Att öppna en befintlig fil för tillägg kräver skrivbehörighet på filen plus sökbehörighet längs varje katalog i dess sökväg. Att skapa en fil kräver skriv- och sökbehörighet på katalogen som innehåller den, eftersom åtgärden lägger till ett namn i den. Att ersätta en fil via namnbyte berör också båda katalogerna och deras sticky bit-regler.

En redan öppen deskriptor lägger till ett fjärde fall. En process kan hålla ett skrivhandtag öppet innan den släppte privilegier och ändå misslyckas med att öppna samma sökväg igen under sin senare identitet. De lyckade tilläggen och det misslyckade skapandet kan båda vara sanna, i samma ögonblick, för samma process.

Standard-ACL:er ärvs, de beviljar inte

En post som börjar med standardprefixet beskriver vad nya objekt ärver från katalogen. Den beviljar ingenting till katalogen själv, och den reparerar inte ACL:n för en fil som redan finns.

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

Läs åtkomstposterna separat från standardposterna, och läs masken. En namngiven post som listar fulla rättigheter kan ändå begränsas av masken, därför betyder den effektiva kommentaren mer än bokstäverna på första raden.

Använd den upplösta sökvägen i stället för sökvägen i konfigurationen. En symbolisk länk, en monteringspunkt eller en roterad katalog kan placera den verkliga filen någonstans dit behörigheten du gav aldrig når. Gå igenom sökvägen med namnverktyget först, jämför sedan varje nivå med det aktuella kontot. Att gissa på toppkatalogen är hur en rättelse landar en nivå för högt.

Identifiera vem som skriver i det ögonblicket

Kontrollera tjänsteenheten, dess drop-ins och daemonens egna kontoinställningar innan du ändrar något. Processen som lägger till och processen som återskapar kan vara olika: en rotationshjälpare, en statusskrivare och en webbläsare delar sällan en identitet.

Ett test kört från ett root-skal återskapar inte en begränsad tjänst, och det kommer att lyckas medan tjänsten fortsätter att misslyckas. Återskapa den misslyckade åtgärden under samma enhet, med samma konto och samma sandlådeinställningar. Om du inte kan, starta enheten med ett tillfälligt skal och kontrollera den identitet den rapporterar. Allt annat mäter din terminal, inte tjänsten.

Om skapandet verkligen behövs, ge skrivaren åtkomst till den dedikerade loggkatalogen och håll läsåtkomsten för konsumenter separat. Att göra ett delat konto eller hela applikationsträdet skrivbart för att tillfredsställa ett enda loggningsanrop byter ett litet problem mot ett stort.

Rotera utan att återinföra problemet

Den som återskapar filen avgör ägaren och läget för nästa cykel, så samordna rättelsen med rotationskonfigurationen. En ersättning som skapats under ett annat konto, eller med en ny ACL, för tillbaka felet efter en lyckad rättelse.

Ställ in läget och gruppen vid skapandet, inte efteråt, och verifiera nästa rotation i stället för nästa tillägg. Ett tillägg upprepar bara testet som redan gått igenom. Om rotationsverktyget erbjuder en inställning för skapandeläge, använd den i stället för en chmod efter skapandet. Gapet mellan skapande och chmod är just det ögonblick då nästa skrivning kan misslyckas.

När avkortning ändå misslyckas, sluta lägga till behörigheter

Att avkortningen av en fil du kan skriva till misslyckas förklaras inte av katalogbehörigheter, och att lägga till fler av dem hjälper inte. Titta i stället på attributen och instängningen: ett append-only-attribut tillåter skrivning bara i tilläggsläge, och en skrivskyddad montering eller en tjänstesandlåda kan neka en åtgärd som ACL:n tillåter.

Kontrollera enhetens filsystembegränsningar och monteringsalternativen för sökvägen, återskapa sedan exakt den åtgärd som misslyckades. Att utöka en behörighet som aldrig rådfrågades döljer bara vilken begränsning som var verklig. Ta bort en begränsning i taget i en engångsenhet, och återställ den innan du ändrar något permanent.