Suchrecht auf jedem Verzeichnis vor dem Schlüssel

Modus 0600 und der richtige Eigentümer garantieren nicht, dass der Dienst einen Schlüssel öffnen kann. Die fehlende Berechtigung liegt meist in einem Verzeichnis darüber. Linux löst einen Pfad Komponente für Komponente auf, und jeder Schritt braucht Suchrecht, bevor der nächste versucht wird. Lesen Sie den ganzen Pfad, nicht die letzte Zeile der Auflistung.

Leserecht ist der letzte Schritt, nicht der einzige

Das Öffnen einer Datei verlangt, dass der Kernel vom Wurzelverzeichnis oder vom Arbeitsverzeichnis aus jede Komponente des Pfads durchläuft. Ein Verzeichnis ohne Suchrecht beendet diesen Durchlauf mit einem Berechtigungsfehler. Der Modus der Datei selbst wird nie geprüft, daher wirkt ein voll lesbarer Schlüssel unlesbar. Der Fehler kommt oft beim Öffnen, ohne das Verzeichnis zu nennen, weshalb die letzte Datei beschuldigt wird.

Bei einem Verzeichnis bedeutet das Ausführungsbit Suche, nicht das Ausführen des Inhalts. Ein Schlüssel bleibt Daten, und kein Teil dieser Reparatur verlangt, ihn als ausführbar zu markieren.

Gehen Sie den Pfad als Dienstkonto

Listen Sie jede Komponente mit Eigentümer und Modus auf, und wiederholen Sie dann das Lesen als tatsächliche Dienstidentität. Der Unterschied zwischen Ihrer Shell und dem Daemon ist oft die ganze Antwort. Folgen Sie symbolischen Links zum echten Ziel, denn geprüft wird der aufgelöste Pfad.

namei -l /etc/openvpn/client/office.key
sudo -u vpn-reader stat -c '%A %U:%G %n' /etc/openvpn/client/office.key

Ein Dienst kann Dateien auch in mehr als einer Phase öffnen. Ein Teil des Materials wird während der privilegierten Einrichtung gelesen, während andere Dateien erst geöffnet werden, nachdem Rechte abgegeben wurden. Eine Root-Shell, die die Datei liest, bildet den Zugriff des späteren Workers nicht nach. Ein Mount-Namensraum kann eine andere Sicht auf denselben Pfad zeigen, besonders in einem Container, also vergleichen Sie die Dateisystemsicht des Daemons mit Ihrer.

Ändern Sie die engste passende Berechtigung

Wählen Sie die kleinste Regelung, die dem Prozess Zugriff gibt: eine kontrollierte Gruppe mit Suche auf den nötigen Verzeichnissen, einen verwalteten Ort, den der Dienst bereits besitzt, oder einen anderen dokumentierten Mechanismus. Das Lesen einer Datei erfordert kein Schreibrecht auf ihrem Verzeichnis. Breites Gruppenschreibrecht auf privilegierter Konfiguration ist keine normale Durchlaufreparatur. Rekursives 0777 ist ebenfalls keine Lösung.

Notieren Sie, welche Komponente Sie geändert haben und warum. Eine Berechtigungsänderung ohne dokumentierten Grund ist schwer zu prüfen und leicht zu vergessen.

Über Modi erst nach dem Durchlauf hinausschauen

Wenn die Modusbits ausreichend erscheinen, sind die restlichen Prüfungen ACLs, Sicherheitsrichtlinie und Sandbox-Einschränkungen. Eine ACL kann Zugriff gewähren, den die Modusbits als fehlend andeuten, oder Zugriff verweigern, den sie zu erlauben scheinen. Diese Einstellungen gehören dem bestehenden Konfigurationseigentümer und sollten eng angepasst statt abgeschaltet werden. Ein Unterschied bei Wurzel- oder Arbeitsverzeichnis kann auch einen absoluten Pfad erklären, der in einem Kontext funktioniert und in einem anderen scheitert.

Verlieren Sie beim Reparieren des Zugriffs nicht aus den Augen, was die Datei ist. Ein CA-Zertifikat ist öffentlich; ein privater Schlüssel nicht. Dateien, die der Client neu schreibt, brauchen andere Schreibrechte als ein Identitätsschlüssel, der schreibgeschützt ist. Prüfen Sie Metadaten, ohne Geheimnisse auszugeben, und bestätigen Sie danach, dass der Dienst selbst nach der Änderung funktioniert. Eine kurze Notiz in der Dienstdokumentation erspart der nächsten Person denselben Durchlauf.