Ce qui s'est passé quand j'ai interdit l'accès root dans tout mon catalogue d'applications
Fabian, Fondateur de Bitflake July 22, 2026
J'ai verrouillé la plateforme : aucune application ne s'exécute en tant que root, les systèmes de fichiers sont en lecture seule par défaut, et chaque application est isolée sur son propre segment réseau afin qu'une application compromise ne puisse pas atteindre les applications des autres. J'ai ensuite redéployé tout le catalogue pour voir ce qui casse.
Les chiffres
Cinquante-deux applications sont passées par ce test. Les applications déjà exclues du catalogue pour des raisons sans rapport n'ont pas fait partie de cette passe, puisqu'elles ne tournent de toute façon pas.
- 17 applications (33 %) ont fonctionné sans aucune modification.
- 26 applications (50 %) ont eu besoin de corrections. Presque toutes du même type : un système de fichiers en lecture seule n'autorise l'écriture que sur les chemins que j'ai explicitement ouverts, et la plupart des images ne documentent pas où elles écrivent.
- 9 applications (17 %) ne peuvent pas du tout fonctionner sans root, et aucune d'elles ne propose de version qui le puisse.
Pourquoi tant d'applications veulent root
Deux schémas couvrent presque tous les cas.
Le premier est PUID/PGID, une convention popularisée par les images LinuxServer.io : le conteneur démarre en tant que root, corrige la propriété des fichiers pour les dossiers qu'il s'apprête à utiliser, puis redescend vers l'ID utilisateur configuré. Cela fonctionne bien sur un serveur personnel où vous possédez toute la machine. Cela ne fonctionne pas du tout si la plateforme refuse d'emblée que le conteneur démarre en tant que root. La correction de propriété n'a alors jamais l'occasion de s'exécuter.
Le second est le port 80. Huit des neuf applications bloquées servent leur interface web sur le port 80 à l'intérieur du conteneur, et seul root est autorisé à écouter sur un port inférieur à 1024 sous Linux. Derrière un reverse proxy, ce qui est la façon dont on accède réellement à chacune de ces applications, cette restriction ne protège rien. C'est un réglage par défaut hérité du passé.
Un schéma plus rare et plus étrange : trois applications ont échoué au moment précis où elles tentaient de cesser d'être root. Leurs points d'entrée abandonnent les privilèges avec des outils comme su-exec ou gosu, et abandonner les privilèges est en soi une opération réservée à root. Une fois que le conteneur n'est plus autorisé à démarrer en tant que root, cette étape échoue aussi. Deux des trois cas ont pu être corrigés en sautant cette étape et en démarrant directement en tant qu'utilisateur cible. Le troisième n'avait pas ce raccourci.
Ce que cela signifie si vous vous auto-hébergez
Rien de tout cela ne rend ces applications mal conçues. Leurs images sont construites pour un serveur de confiance unique, où démarrer en tant que root pour corriger quelques permissions de fichiers est une simple commodité, pas un risque. Une plateforme partagée qui fait tourner des dizaines d'applications sans rapport les unes avec les autres est un environnement différent : si une application est compromise, l'accès root à l'intérieur de son conteneur offre à un attaquant une surface d'attaque bien plus large contre le noyau, la couche censée le tenir à l'écart des données de tous les autres.
Si vous auto-hébergez vous-même l'une de ces applications, cela vaut la peine de vérifier comment elle démarre. L'indice le plus rapide se trouve dans la documentation : si une image parle de PUID et PGID, elle démarre en tant que root avant de redescendre. Les Pod Security Standards de Kubernetes documentent le profil « restricted » qui exclut cela, et c'est désormais le profil que j'applique à tout.
Ce qu'il advient des neuf
Pour l'instant, aucune des neuf ne tourne sur le catalogue Bitflake. Je n'ai pas décidé si c'est permanent. Les options sont une correction en amont, une image différente, ou une exception limitée à la règle sans root. Chacune a ses propres compromis, et je préfère y réfléchir correctement plutôt que d'en choisir une maintenant.