Jurnalul crește, dar nu poate fi recreat: verificați ACL-ul directorului
Adăugarea într-un fișier nu necesită un nume nou în directorul său; crearea da. Comparați ACL-ul de acces cu valorile implicite moștenite înainte de a extinde ceva.
Un jurnal care crește continuu se oprește din creștere în momentul în care ceva îl recreează, iar eroarea spune că permisiunea a fost refuzată. Concluzia tentantă este că fișierul de jurnal însuși are nevoie de mai multe permisiuni, însă fișierul poate fi deja scriibil de același cont. Adăugarea la un nume existent și crearea unui nume nou sunt două verificări diferite, și doar a doua consultă directorul.
Adăugarea și crearea sunt verificări diferite
Deschiderea unui fișier existent pentru adăugare necesită acces de scriere pe acel fișier plus acces de căutare de-a lungul fiecărui director din calea lui. Crearea unui fișier necesită scriere și căutare în directorul care îl conține, deoarece operația îi adaugă un nume. Înlocuirea unui fișier printr-o redenumire atinge și ambele directoare, și regulile lor de sticky bit.
| Operation | What must permit it | Typical failure message |
|---|---|---|
| Append to an existing log | File write access, path traversal | Permission denied on the file |
| Create a missing log | Directory write and search access | Permission denied on the path |
| Rename a replacement into place | Both directories, plus sticky restrictions | Permission denied or operation not permitted |
Un descriptor deja deschis adaugă un al patrulea caz. Un proces poate ține un handle de scriere deschis înainte de a renunța la privilegii și totuși poate eșua la redeschiderea aceleiași căi sub identitatea sa ulterioară. Adăugările reușite și crearea eșuată pot fi ambele adevărate, în același moment, pentru același proces.
ACL-urile implicite se moștenesc, nu acordă
O intrare care începe cu prefixul implicit descrie ce moștenesc obiectele noi din director. Nu acordă nimic directorului însuși și nu repară ACL-ul unui fișier care există deja.
namei -l /var/log/openvpn/server.log
getfacl -p /var/log/openvpn
getfacl -p /var/log/openvpn/server.logCitiți intrările de acces separat de cele implicite și citiți masca. O intrare numită care listează drepturi complete poate fi totuși limitată de mască, de aceea comentariul efectiv contează mai mult decât literele de pe primul rând.
Folosiți calea rezolvată, nu calea din configurație. O legătură simbolică, un punct de montare sau un director rotit pot pune fișierul real unde permisiunea acordată nu ajunge niciodată. Parcurgeți mai întâi calea cu instrumentul de nume, apoi comparați fiecare nivel cu contul în cauză. Ghidarea după directorul de nivel superior este modul în care o corectare aterizează un nivel prea sus.
Identificați cine scrie în acel moment
Verificați unitatea de serviciu, drop-in-urile ei și setările de cont ale daemonului însuși înainte de a schimba ceva. Procesul care adaugă și procesul care recreează pot fi diferite: un ajutor de rotație, un scriitor de stare și un cititor web împart rar o identitate.
Un test rulat dintr-un shell root nu reproduce un serviciu restricționat, și va reuși în timp ce serviciul continuă să eșueze. Reproduceți operația eșuată sub aceeași unitate, cu același cont și aceleași setări de sandbox. Dacă nu puteți, porniți unitatea cu un shell temporar și verificați identitatea pe care o raportează. Orice altceva măsoară terminalul dumneavoastră, nu serviciul.
Dacă crearea este cu adevărat necesară, acordați scriitorului acces la directorul de jurnal dedicat și țineți accesul de citire pentru consumatori separat. A face un cont partajat sau întregul arbore al aplicației scriibil pentru a satisface un singur apel de jurnalizare schimbă o problemă mică pe una mare.
Rotiți fără a reintroduce problema
Cine recreează fișierul decide proprietarul și modul pentru ciclul următor, așa că coordonați corectarea cu configurația de rotație. O înlocuire creată sub alt cont, sau cu un ACL nou, readuce eșecul după o corectare reușită.
Setați modul și grupul la creare, nu după, și verificați următoarea rotație, nu următoarea adăugare. O adăugare doar repetă testul care a trecut deja. Dacă instrumentul de rotație oferă o setare pentru modul de creare, folosiți-o în locul unui chmod după creare. Intervalul dintre creare și chmod este exact momentul în care următoarea scriere poate eșua.
Când trunchierea eșuează totuși, opriți adăugarea de permisiuni
Eșecul de a trunchia un fișier în care puteți scrie nu se explică prin permisiunile directorului, iar adăugarea altora nu va ajuta. Uitați-vă în schimb la atribute și la izolare: un atribut append-only permite scrieri doar în modul de adăugare, iar o montare doar-citire sau un sandbox de serviciu pot refuza o operație pe care ACL-ul o permite.
Verificați restricțiile sistemului de fișiere al unității și opțiunile de montare pentru cale, apoi reproduceți operația exactă care a eșuat. Extinderea unei permisiuni care nu a fost niciodată consultată doar ascunde care restricție era reală. Eliminați o restricție pe rând într-o unitate de unică folosință și readuceți-o înainte de a schimba ceva permanent.