Zum Inhalt

SELinux: Permission denied

Ungeprüft

Diese Anleitung ist noch nicht durchgespielt worden; Befehle, Bezeichnungen und erwartete Ausgaben können abweichen. Was noch zu prüfen ist, steht in todo/doku.md.

Nie SELinux abschalten, nie Labels von Hand setzen

setenforce 0 nimmt allen Containern auf dem Host den Schutz voreinander, auch wenn es den Fehler scheinbar sofort behebt. chcon oder restorecon auf einem Volume behebt den Fehler nur bis zum nächsten Start des Containers oder Neuaufbau des Hosts. Behoben wird immer in der Stack-Datei und mit apply; siehe Was man von Hand darf.

Ziel

Ein Container, der wegen SELinux nicht an die Dateien in einem Volume kommt, hat wieder Zugriff, weil die Volume-Option in der Stack-Datei stimmt.

Voraussetzungen

Die Beispiele nutzen hedgedoc-server auf werner. Die Befehle in Schritt 1 bis 3 laufen auf dem Host, nach ssh werner.garage-lab.de.

Schritte

1. Fehlermeldung im Log finden

Bash
1
journalctl -u hedgedoc-server.service -n 100 --no-pager | grep -i "permission denied"

Erwartet: eine oder mehrere Zeilen mit Permission denied und einem Pfad im Container, etwa /hedgedoc/public/uploads. Notiere den Pfad. Wie du die Logs sonst liest, steht in Container-Status und Logs ansehen.

2. SELinux als Ursache bestätigen

Bash
1
ausearch -m avc -ts recent

-ts recent zeigt die letzten zehn Minuten; für einen älteren Fehler nimm etwa -ts today.

Erwartet: Einträge wie dieser, einer je verweigertem Zugriff:

Text Only
1
type=AVC msg=audit(1759561234.567:891): avc:  denied  { write } for  pid=4242 comm="node" name="uploads" dev="sda1" ino=123456 scontext=system_u:system_r:container_t:s0:c120,c845 tcontext=system_u:object_r:container_file_t:s0:c311,c702 tclass=dir permissive=0
  • comm ist das Programm im Container, name die Datei oder der Ordner.
  • scontext ist das Label des Containers, tcontext das Label der Datei.

Steht dort <no matches>, liegt es nicht an SELinux, sondern etwa an den Dateirechten; dann hilft meist die Option U (siehe Volume-Optionen), oder der Fehler liegt in der App.

Wenn das Paket policycoreutils-python-utils installiert ist, erklärt ausearch -m avc -ts recent | audit2why jeden Eintrag zusätzlich in Worten.

3. Betroffenes Volume finden

Welche Volumes und Ordner unter welchem Pfad im Container eingebunden sind:

Bash
1
podman inspect hedgedoc-server --format '{{range .Mounts}}{{.Name}} {{.Source}} -> {{.Destination}}{{"\n"}}{{end}}'

Erwartet: eine Zeile je Einbindung, etwa hedgedoc-server-uploads /var/lib/containers/storage/volumes/hedgedoc-server-uploads/_data -> /hedgedoc/public/uploads. Bei einem Bind-Mount ist der Name leer. Such die Zeile, deren Pfad zu Schritt 1 passt, und sieh dir das Label der Quelle an:

Bash
1
ls -Zd /var/lib/containers/storage/volumes/hedgedoc-server-uploads/_data

Erwartet: das Label aus tcontext in Schritt 2.

4. Richtige Option bestimmen

Vergleiche tcontext aus Schritt 2 mit scontext und such das Volume in den Stack-Dateien des Hosts:

Bash
1
grep -n "hedgedoc-server-uploads" syslet/werner/*.cue

Das machst du auf deinem Rechner, im Repo-Ordner. Erwartet: jede Stelle, an der ein Container das Volume einbindet, mit seiner Option, und gegebenenfalls ein backup:-Eintrag.

Was du siehst Ursache Richtige Option
tcontext ist container_file_t mit anderen Kategorien (c311,c702) als scontext; das Volume binden mehrere Container ein oder es steht in einem backup:-Block Ein anderer Container hat es mit Z privat gemacht überall z (Falsches Z auf einem geteilten Volume)
tcontext ist kein container_file_t, etwa var_t oder default_t; es ist ein Bind-Mount ohne Option Der Ordner hat noch das Label vom Host Z, oder z, wenn mehrere Container ihn brauchen (Was ohne Option passiert)
Der Pfad ist ein Systempfad des Hosts oder ein NFS-Mount Ausnahme, Relabeln ist dort falsch keine Option ändern; in Signal nachfragen (Ausnahmen)

5. Option in der Stack-Datei korrigieren und ausrollen

Ändere die Option hinter dem Pfad, etwa "/hedgedoc/public/uploads:rw,Z" zu "/hedgedoc/public/uploads:rw,z", bei jedem Container, der das Volume einbindet. Roll die Änderung aus wie in Änderung ausrollen.

Erwartet: cue cmd plan zeigt nur die betroffenen Container als geändert, mit der neuen Option in der Zeile Volume=, und sie werden beim apply neu gestartet.

Prüfen

  • systemctl status hedgedoc-server.service auf dem Host zeigt active (running).
  • ausearch -m avc -ts recent zeigt nach dem Neustart keine neuen Einträge für den Container.
  • Die App kann wieder schreiben, etwa eine Datei hochladen.
  • Starte auch die anderen Container, die das Volume nutzen, einmal neu, damit ein späterer Neustart nicht wieder einen davon aussperrt; siehe Gecrashten Dienst neu starten.

Wenn etwas schiefgeht