Perché un container inizia a creare file di proprietà di root solo dopo un aggiornamento dell’immagine?
Un container può creare file di proprietà di root dopo un aggiornamento dell’immagine quando la nuova immagine modifica l’utente di runtime, l’entrypoint o la procedura di assegnazione della proprietà all’avvio.
Il volume persistente può rimanere invariato mentre il container sostitutivo viene avviato con un UID numerico diverso oppure esegue brevemente un’inizializzazione come root. Un nuovo entrypoint può creare directory mancanti, migrare la configurazione, riscrivere i permessi o smettere di rispettare le variabili PUID e PGID usate dalla versione precedente. Confronta un file precedente all’aggiornamento, un file creato all’avvio e un file creato dall’applicazione in esecuzione prima di applicare modifiche ricorsive alla proprietà.
Dimostra che la proprietà cambia solo dopo l’avvio del container aggiornato
Arresta lo stack e registra UID numerico, GID, modalità, ACL e timestamp di un file esistente e della relativa directory padre. Avvia una volta il container aggiornato con i log visibili, quindi controlla lo stesso percorso e un file appena creato.
Le chiamate di sistema Linux chown modificano la proprietà numerica, quindi l’evidenza decisiva è costituita da UID e GID prima e dopo l’avvio, non dal nome utente visualizzato dall’host.
Se la proprietà è già di root prima dell’avvio, l’aggiornamento non è la causa iniziale. Indaga sulla copia, sull’estrazione, sul ripristino del backup o sul comando dell’amministratore che ha scritto i file.
Confronta l’utente dell’immagine prima e dopo l’aggiornamento
Esamina la configurazione delle immagini vecchia e nuova, l’utente effettivo del container, l’entrypoint, il comando e le note di rilascio. Verifica se l’immagine ora dichiara root, un account denominato o un UID numerico diverso.
Docker documenta che l’istruzione USER imposta l’identità di runtime per le istruzioni successive dell’immagine e per l’entrypoint e il comando del container, quando nessun override di runtime la sostituisce.
Un’immagine può mantenere lo stesso nome utente dell’applicazione cambiandone però l’UID numerico. Confronta i numeri in entrambe le versioni dell’immagine, perché i file montati dall’host memorizzano la proprietà numerica, non l’etichetta del nome utente dell’immagine.
Verifica se il nuovo entrypoint esegue un chown ricorsivo
Cerca nei log di avvio, nelle note di rilascio, negli script dell’entrypoint e nelle tracce dei processi riferimenti a chown, riparazione dei permessi, PUID, PGID, migrazione degli utenti o inizializzazione delle directory. Esegui il test su un piccolo snapshot o su un volume usa e getta.
GNU Coreutils definisce il chown ricorsivo come una riscrittura della proprietà sull’albero di directory selezionato, il che può far sembrare che un volume esistente e corretto sia cambiato immediatamente dopo l’avvio della nuova immagine.
Non rimuovere alla cieca la riparazione all’avvio. Alcune immagini dipendono da essa per le directory appena create. Quando l’immagine lo supporta, preferisci un’opzione documentata per disabilitarla, un UID fisso per l’applicazione o un percorso dati più specifico.
Controlla gli override dell’utente in Compose e le variabili PUID o PGID rimosse
Confronta il modello Compose distribuito prima e dopo l’aggiornamento, includendo user:, le variabili d’ambiente, i gruppi supplementari, i profili, i file di override e le impostazioni memorizzate dal gestore dello stack.
Kubernetes usa identità numeriche esplicite per il runtime e i volumi, illustrando lo stesso confine del container: un override di runtime e una policy sulla proprietà del volume sono impostazioni separate che devono rimanere allineate.
Se la vecchia immagine traduceva le variabili PUID e PGID ma la nuova versione le ha rimosse o rinominate, le variabili possono rimanere presenti senza controllare più il processo. Verifica direttamente l’UID in esecuzione.
Tieni conto della modalità rootless e della mappatura degli ID dello spazio dei nomi utente
Annota se Docker viene eseguito in modalità rootful, rootless o con la rimappatura dello spazio dei nomi utente. Confronta l’UID visibile nel container con il proprietario visibile sull’host dello stesso inode.
Red Hat spiega che i container rootless usano intervalli di UID e GID subordinati, quindi root nel container non appare necessariamente come UID host 0 e un aggiornamento può rendere evidente una mappatura o una modalità di runtime cambiata.
Non eseguire un chown ricorsivo di un volume rootless assegnandolo a root sull’host senza comprendere la mappatura. Potresti rendere i dati inaccessibili all’identità prevista del container.
Verifica se un mount idmapped o di rete modifica il proprietario visualizzato
Identifica se i dati dell’app si trovano su un filesystem locale, su un mount idmapped, NFS, SMB, FUSE o su una condivisione NAS. Registra le opzioni di mount e confronta la proprietà dal server, dall’host e dal container.
Il modello Linux dei mount idmapped separa la proprietà del filesystem da quella del mount, quindi lo stesso file può apparire con ID diversi senza una riscrittura fisica ricorsiva della proprietà.
Se cambia solo il proprietario visualizzato dopo l’aggiornamento, verifica se il runtime ora accede a uno spazio dei nomi o a una mappatura del mount diversi. Correggi la mappatura invece di riscrivere ogni inode.
Ripristina un’identità di runtime stabile e verifica l’aggiornamento successivo
Esegui il backup dei metadati della proprietà, arresta l’app, definisci l’UID e il GID numerici previsti, correggi solo i percorsi di proprietà dell’app e ridistribuisci con un’immagine fissata e impostazioni utente documentate.
L’articolo di ZimaSpace sulla proprietà dei container dopo la copia dei dati delle app tratta le cause legate a copia e migrazione; questo articolo isola un cambiamento introdotto dall’immagine sostitutiva.
La riparazione è completa quando l’avvio, le scritture dell’applicazione, la ricreazione del container, il riavvio dell’host e un aggiornamento controllato dell’immagine creano tutti file con l’identità documentata, senza ampie eccezioni sui permessi.
Domande frequenti
Un file di proprietà di root dimostra che l’intero container viene eseguito come root?
No. Un entrypoint può essere eseguito brevemente come root per inizializzare un volume e poi ridurre i privilegi prima dell’avvio dell’applicazione.
Devo eseguire un chown ricorsivo sull’intero volume?
Non prima di aver identificato l’UID previsto, i percorsi condivisi, le ACL e la mappatura dello spazio dei nomi. Una riscrittura generale può danneggiare database, contenuti multimediali condivisi o la proprietà dei container rootless.
Un aggiornamento dell’immagine può cambiare l’UID dell’applicazione?
Sì. I manutentori possono cambiare l’utente dell’immagine, ricostruire il database degli account, rinominare le impostazioni PUID o PGID oppure aggiungere una migrazione della proprietà all’avvio.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...
Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...
Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...
