Was passierte, als ich Root-Zugriff im gesamten App-Katalog verboten habe
Fabian, Gründer von Bitflake 22. Juli 2026
Ich habe die Plattform abgesichert: Keine App läuft als Root, Dateisysteme sind standardmäßig nur lesbar, und jede App ist auf ihrem eigenen Netzwerksegment isoliert, sodass eine kompromittierte App nicht auf die Apps anderer zugreifen kann. Anschließend habe ich den gesamten Katalog neu ausgerollt, um zu sehen, was dabei kaputtgeht.
Die Zahlen
52 Apps wurden getestet. Apps, die bereits aus anderen, unabhängigen Gründen vom Katalog ausgeschlossen sind, waren nicht Teil dieses Durchlaufs, da sie ohnehin nicht laufen.
- 17 Apps (33 %) liefen ohne Änderungen.
- 26 Apps (50 %) benötigten Anpassungen. Fast alle betrafen dieselbe Art von Problem: Ein nur lesbares Dateisystem erlaubt Schreibzugriffe nur auf Pfade, die ich explizit freigegeben habe, und die meisten Images dokumentieren nicht, wohin sie schreiben.
- 9 Apps (17 %) können ohne Root überhaupt nicht laufen, und keine von ihnen bietet eine Version an, die das könnte.
Warum so viele Apps Root wollen
Zwei Muster erklären fast alles.
Das erste ist PUID/PGID, eine von LinuxServer.io-Images populär gemachte Konvention: Der Container startet als Root, korrigiert die Dateibesitzverhältnisse für die Ordner, die er gleich verwenden wird, und wechselt dann zur konfigurierten Benutzer-ID. Auf einem Heimserver, auf dem man die gesamte Maschine selbst besitzt, funktioniert das gut. Es funktioniert überhaupt nicht, wenn die Plattform dem Container von vornherein verweigert, als Root zu starten. Die Korrektur der Besitzverhältnisse kommt dann nie zum Einsatz.
Das zweite ist Port 80. Acht der neun blockierten Apps stellen ihre Weboberfläche innerhalb des Containers auf Port 80 bereit, und unter Linux darf nur Root einen Port unterhalb von 1024 binden. Hinter einem Reverse-Proxy – und genau so wird jede dieser Apps tatsächlich erreicht – schützt diese Einschränkung nichts. Es ist eine überholte Standardeinstellung.
Ein kleineres, ungewöhnlicheres Muster: Drei Apps scheiterten genau in dem Moment, in dem sie aufhören wollten, Root zu sein. Ihre Entrypoints geben Privilegien mit Tools wie su-exec oder gosu ab, und das Abgeben von Privilegien ist selbst eine Operation, die nur Root ausführen darf. Sobald der Container nicht mehr als Root starten darf, schlägt auch dieser Schritt fehl. Bei zwei der drei ließ sich das beheben, indem dieser Schritt übersprungen und direkt als Zielbenutzer gestartet wurde. Bei der dritten gab es keine solche Abkürzung.
Was das für Selbst-Hosting bedeutet
Das macht diese Apps nicht schlecht gebaut. Ihre Images sind für einen einzelnen vertrauenswürdigen Server konzipiert, auf dem es eine kleine Bequemlichkeit und kein Risiko ist, als Root zu starten, um ein paar Dateiberechtigungen zu korrigieren. Eine gemeinsam genutzte Plattform, auf der Dutzende voneinander unabhängige Apps nebeneinander laufen, ist eine andere Umgebung: Wird eine App kompromittiert, verschafft Root-Zugriff innerhalb ihres Containers einem Angreifer eine deutlich größere Angriffsfläche gegen den Kernel – die Schicht, die eigentlich verhindern soll, dass er an die Daten aller anderen gelangt.
Wenn Sie eine dieser Apps selbst hosten, lohnt es sich zu prüfen, wie sie starten. Der schnellste Hinweis findet sich in der Dokumentation: Wenn ein Image von PUID und PGID spricht, startet es als Root und wechselt später den Benutzer. Die Pod Security Standards von Kubernetes dokumentieren das Profil „restricted", das genau das ausschließt – und das ist das Profil, gegen das ich jetzt alles laufen lasse.
Wo das die neun zurücklässt
Vorerst läuft keine der neun im Bitflake-Katalog. Ich habe noch nicht entschieden, ob das dauerhaft so bleibt. Die Optionen sind ein Fix vom Upstream-Projekt, ein anderes Image oder eine eng begrenzte Ausnahme von der No-Root-Regel. Jede hat ihre eigenen Kompromisse, und ich möchte das lieber gründlich durchdenken, als jetzt schon eine davon zu wählen.