Cosa è successo quando ho vietato l'accesso root in tutto il mio catalogo di app
Fabian, Fondatore di Bitflake July 22, 2026
Ho blindato la piattaforma: nessuna app viene eseguita come root, i filesystem sono di sola lettura per impostazione predefinita e ogni app è isolata sul proprio segmento di rete, così un'app compromessa non può raggiungere le app di nessun altro. Poi ho ridistribuito l'intero catalogo per vedere cosa si rompeva.
I numeri
Cinquantadue app sono passate per il test. Le app già escluse dal catalogo per motivi non correlati non hanno fatto parte di questo giro, dato che comunque non sono in esecuzione.
- 17 app (33%) hanno funzionato senza modifiche.
- 26 app (50%) hanno richiesto correzioni. Quasi tutte dello stesso tipo: un filesystem di sola lettura consente scritture solo nei percorsi che ho aperto esplicitamente, e la maggior parte delle immagini non documenta dove scrive.
- 9 app (17%) non possono funzionare affatto senza root, e nessuna di esse offre una versione che lo permetta.
Perché così tante app vogliono root
Due schemi coprono quasi tutti i casi.
Il primo è PUID/PGID, una convenzione resa popolare dalle immagini di LinuxServer.io: il container parte come root, corregge la proprietà dei file per le cartelle che sta per usare, poi passa all'ID utente configurato. Funziona bene su un server domestico dove si possiede l'intera macchina. Non funziona affatto se la piattaforma rifiuta di far partire il container come root fin dall'inizio. La correzione della proprietà non ha mai la possibilità di essere eseguita.
Il secondo è la porta 80. Otto delle nove app bloccate servono la propria interfaccia web sulla porta 80 all'interno del container, e su Linux solo root può aprire una porta sotto la 1024. Dietro un reverse proxy, che è il modo in cui ognuna di queste app viene effettivamente raggiunta, quella restrizione non protegge nulla. È un'impostazione predefinita rimasta dal passato.
Uno schema più piccolo e più strano: tre app hanno fallito nell'esatto momento in cui cercavano di smettere di essere root. I loro entrypoint abbandonano i privilegi con strumenti come su-exec o gosu, e abbandonare i privilegi è a sua volta un'operazione riservata a root. Una volta che al container non è più permesso partire come root, anche questo passaggio fallisce. Due delle tre potevano essere corrette saltando quel passaggio e partendo direttamente come utente target. La terza non aveva questa scorciatoia.
Cosa significa se ospita queste app autonomamente
Niente di tutto questo rende queste app mal costruite. Le loro immagini sono pensate per un singolo server fidato, dove partire come root per correggere qualche permesso sui file è una comodità minore, non un rischio. Una piattaforma condivisa che esegue dozzine di app non correlate fianco a fianco è un ambiente diverso: se un'app viene compromessa, l'accesso root all'interno del suo container dà a un aggressore una superficie di attacco molto più ampia contro il kernel, il livello che dovrebbe tenerla lontana dai dati di chiunque altro.
Se sta ospitando autonomamente una di queste app, vale la pena controllare come parte. Il segnale più rapido è nella documentazione: se un'immagine parla di PUID e PGID, parte come root e passa a un altro utente più tardi. I Pod Security Standards di Kubernetes documentano il profilo "restricted" che esclude questo comportamento, ed è il profilo su cui ora eseguo tutto.
A che punto sono le nove app
Per ora, nessuna delle nove è in esecuzione sul catalogo Bitflake. Non ho deciso se sia permanente. Le opzioni sono una correzione a monte, un'immagine diversa o un'eccezione mirata alla regola no-root. Ognuna ha i propri compromessi, e preferisco pensarci con cura piuttosto che sceglierne una adesso.