Anhängen klappt, Neuerstellen nicht: Verzeichnis-ACL prüfen

Eine Protokolldatei, die immer weiter wächst, hört in dem Moment auf zu wachsen, in dem etwas sie neu erstellt, und die Fehlermeldung lautet Zugriff verweigert. Die naheliegende Schlussfolgerung ist, dass die Datei selbst mehr Rechte braucht, obwohl dieselbe Kennung vielleicht schon schreiben darf. An einen vorhandenen Namen anzuhängen und einen neuen anzulegen sind unterschiedliche Prüfungen, und nur die zweite befragt das Verzeichnis.

Anhängen und Anlegen sind unterschiedliche Prüfungen

Eine vorhandene Datei zum Anhängen zu öffnen verlangt Schreibrecht auf dieser Datei und Suchrecht auf jedem Verzeichnis in ihrem Pfad. Eine Datei anzulegen verlangt Schreib- und Suchrecht auf dem enthaltenden Verzeichnis, weil der Vorgang dort einen Namen hinzufügt. Das Ersetzen einer Datei per Umbenennen berührt beide Verzeichnisse und deren Sticky-Bit-Regeln.

Ein bereits geöffneter Deskriptor fügt einen vierten Fall hinzu. Ein Prozess kann ein beschreibbares Handle halten, das vor dem Absenken seiner Rechte geöffnet wurde, und trotzdem denselben Pfad unter seiner späteren Identität nicht erneut öffnen. Die erfolgreichen Anhänge und das gescheiterte Anlegen können gleichzeitig für denselben Prozess zutreffen.

Standard-ACLs vererben, sie gewähren nichts

Ein Eintrag mit dem Standard-Präfix beschreibt, was neue Objekte vom Verzeichnis erben. Er gewährt dem Verzeichnis selbst nichts und repariert auch nicht die ACL einer bereits vorhandenen Datei.

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

Lies die Zugriffseinträge getrennt von den Standardeinträgen und lies die Maske. Ein benannter Eintrag mit vollen Rechten kann trotzdem durch die Maske begrenzt sein; deshalb sagt der Vermerk zur wirksamen Maske mehr aus als die Buchstaben in der ersten Zeile.

Verwende den aufgelösten Pfad statt des Pfads aus der Konfiguration. Ein Symlink, ein Einhängepunkt oder ein rotiertes Verzeichnis kann die echte Datei dorthin bringen, wo das erteilte Recht nie ankommt. Gehe den Pfad zuerst mit namei ab und vergleiche dann jede Ebene mit dem fraglichen Konto. Wer beim obersten Verzeichnis rät, setzt die Korrektur eine Ebene zu hoch an.

Finde heraus, wer in diesem Moment schreibt

Prüfe die Dienst-Unit, ihre Drop-ins und die Kontoeinstellungen des Daemons, bevor du etwas änderst. Der Prozess, der anhängt, und der Prozess, der neu erstellt, können verschieden sein: ein Rotationshelfer, ein Status-Schreiber und ein Web-Leser teilen selten dieselbe Identität.

Ein Testlauf aus einer Root-Shell bildet einen eingeschränkten Dienst nicht nach, und er wird gelingen, während der Dienst weiter scheitert. Reproduziere den fehlschlagenden Vorgang unter derselben Unit, mit demselben Konto und denselben Sandbox-Einstellungen. Wenn dir das nicht gelingt, starte die Unit mit einer temporären Shell und prüfe die Identität, die sie meldet. Alles andere misst dein Terminal statt den Dienst.

Wenn das Anlegen wirklich nötig ist, gib dem Schreiber Zugriff auf das eigene Log-Verzeichnis und halte den Lesezugriff für Konsumenten getrennt. Ein gemeinsames Konto oder einen ganzen Anwendungsbaum beschreibbar zu machen, nur damit ein Logging-Aufruf funktioniert, tauscht ein kleines Problem gegen ein großes.

Rotieren, ohne den Fehler wieder einzuführen

Wer die Datei neu erstellt, entscheidet für den nächsten Zyklus über Eigentümer und Modus; stimme die Korrektur daher mit der Rotationskonfiguration ab. Ein Ersatz, der unter einem anderen Konto oder mit einer frischen ACL entsteht, bringt den Fehler nach einer erfolgreichen Korrektur zurück.

Setze Modus und Gruppe beim Anlegen, nicht danach, und prüfe die nächste Rotation statt den nächsten Anhang. Ein Anhang wiederholt nur den Test, der schon bestanden ist. Wenn das Rotationswerkzeug eine Einstellung für den Anlegemodus bietet, nutze sie statt eines chmod danach. Die Lücke zwischen Anlegen und chmod ist genau der Zeitpunkt, an dem der nächste Schreibvorgang scheitern kann.

Wenn das Kürzen trotzdem scheitert, keine weiteren Rechte erteilen

Ein Fehlschlag beim Kürzen einer Datei, die du beschreiben kannst, erklärt sich nicht durch Verzeichnisrechte, und mehr davon werden nicht helfen. Sieh stattdessen auf Attribute und auf die Einschränkung: Ein append-only-Attribut erlaubt Schreiben nur im Anhängemodus, und ein schreibgeschützt eingebundenes Dateisystem oder eine Dienst-Sandbox kann einen Vorgang verweigern, den die ACL erlaubt.

Prüfe die Dateisystem-Beschränkungen der Unit und die Einhängeoptionen für den Pfad und reproduziere dann den genauen Vorgang, der fehlgeschlagen ist. Ein Recht zu erweitern, das nie befragt wurde, verdeckt nur, welche Beschränkung wirklich ursächlich war. Entferne jeweils eine Beschränkung in einer Wegwerf-Unit und nimm sie zurück, bevor du etwas Dauerhaftes änderst.