¿Por qué un contenedor empieza a crear archivos propiedad de root solo después de una actualización de la imagen?
Un contenedor puede crear archivos propiedad de root después de una actualización de imagen cuando la nueva imagen cambia su usuario de ejecución, punto de entrada o rutina de asignación de propietarios durante el inicio.
El volumen persistente puede permanecer sin cambios mientras el contenedor reemplazado se inicia con un UID numérico diferente o ejecuta brevemente un paso de inicialización como root. Un nuevo punto de entrada puede crear directorios inexistentes, migrar la configuración, reescribir permisos o dejar de respetar las variables PUID y PGID utilizadas por la versión anterior. Compara un archivo anterior a la actualización, un archivo creado durante el inicio y un archivo creado por la aplicación en ejecución antes de aplicar cambios de propiedad recursivos.
Demuestra que la propiedad cambia solo después de iniciar el contenedor actualizado
Detén la pila y registra el UID numérico, el GID, el modo, las ACL y las marcas de tiempo de un archivo existente y de su directorio principal. Inicia una vez el contenedor actualizado con los registros visibles y, después, inspecciona la misma ruta y un archivo recién creado.
Las llamadas al sistema chown de Linux cambian la propiedad numérica, por lo que la evidencia decisiva es el UID y el GID antes y después del inicio, no el nombre de usuario que muestra el host.
Si la propiedad ya es de root antes del inicio, la actualización no es la causa inicial. Investiga la copia de la actualización, la extracción, la restauración de una copia de seguridad o el comando administrativo que escribió los archivos.
Compara el usuario de la imagen antes y después de la actualización
Inspecciona la configuración de las imágenes antigua y nueva, el usuario efectivo del contenedor, el punto de entrada, el comando y las notas de la versión. Registra si la imagen ahora declara root, una cuenta con nombre o un UID numérico diferente.
Docker documenta que la instrucción USER establece la identidad de ejecución para las instrucciones posteriores de la imagen y para el punto de entrada y el comando del contenedor cuando ningún reemplazo en tiempo de ejecución la sustituye.
Una imagen puede conservar el mismo nombre de usuario de la aplicación y cambiar su UID numérico. Compara los números dentro de ambas versiones de la imagen, porque los archivos montados desde el host almacenan la propiedad numérica, no la etiqueta del nombre de usuario de la imagen.
Comprueba si el nuevo punto de entrada ejecuta un chown recursivo
Busca en los registros de inicio, las notas de la versión, los scripts del punto de entrada y las trazas de procesos términos como chown, reparación de permisos, PUID, PGID, migración de usuarios o inicialización de directorios. Haz la prueba con una instantánea pequeña o un volumen desechable.
GNU Coreutils define chown recursivo como una reescritura de la propiedad en todo el árbol de directorios seleccionado, lo que puede hacer que un volumen existente correcto parezca cambiar inmediatamente después de iniciar la nueva imagen.
No elimines a ciegas la reparación durante el inicio. Algunas imágenes dependen de ella para los directorios recién creados. Prefiere un indicador documentado para omitirla, un UID fijo de la aplicación o una ruta de datos más específica cuando la imagen admita alguna de estas opciones.
Audita las anulaciones de usuario de Compose y las variables PUID o PGID eliminadas
Compara el modelo de Compose implementado antes y después de la actualización, incluidos user:, las variables de entorno, los grupos suplementarios, los perfiles, los archivos de anulación y la configuración almacenada por el gestor de pilas.
Kubernetes utiliza identidades numéricas explícitas de ejecución y de volumen, lo que ilustra el mismo límite del contenedor: una anulación de ejecución y una política de propiedad del volumen son configuraciones independientes que deben mantenerse alineadas.
Si la imagen antigua traducía las variables PUID y PGID, pero la nueva versión las eliminó o cambió de nombre, las variables pueden seguir presentes sin controlar ya el proceso. Verifica directamente el UID en ejecución.
Ten en cuenta la ejecución sin root y la asignación de identificadores mediante espacios de nombres de usuario
Registra si Docker se ejecuta con root, sin root o con reasignación de espacios de nombres de usuario. Compara el UID visible dentro del contenedor con el propietario visible en el host del mismo inodo.
Red Hat explica que los contenedores sin root utilizan rangos de UID y GID subordinados, por lo que root dentro del contenedor no necesariamente aparece como el UID 0 del host, y una actualización puede revelar una asignación o un modo de ejecución diferente.
No hagas un chown recursivo de un volumen sin root para asignarlo a root del host sin comprender la asignación. Eso puede impedir que la identidad de contenedor prevista acceda a los datos.
Comprueba si un montaje con asignación de identificadores o de red cambia el propietario visible
Identifica si los datos de la aplicación están en un sistema de archivos local, un montaje con asignación de identificadores, NFS, SMB, FUSE o un recurso compartido NAS. Registra las opciones de montaje y compara la propiedad desde el servidor, el host y el contenedor.
El modelo de montajes con asignación de identificadores del kernel de Linux separa la propiedad del sistema de archivos de la propiedad del montaje, por lo que el mismo archivo puede aparecer con distintos ID sin una reescritura física recursiva de la propiedad.
Si solo cambia el propietario mostrado después de la actualización, verifica si el tiempo de ejecución entra ahora en otro espacio de nombres o utiliza una asignación de montaje diferente. Repara la asignación en lugar de reescribir todos los inodos.
Restablece una identidad de ejecución estable y verifica la siguiente actualización
Haz una copia de seguridad de los metadatos de propiedad, detén la aplicación, define el UID y el GID numéricos previstos, corrige únicamente las rutas propiedad de la aplicación y vuelve a implementarla con una imagen fijada y una configuración de usuario documentada.
El artículo de ZimaSpace sobre la propiedad de los contenedores después de copiar datos de aplicaciones aborda las causas relacionadas con copias y migraciones; este artículo aísla un cambio introducido por la imagen de reemplazo.
La reparación está completa cuando el inicio, las escrituras de la aplicación, la recreación del contenedor, el reinicio del host y una actualización controlada de la imagen crean archivos con la identidad documentada, sin excepciones generales de permisos.
Preguntas frecuentes
¿Un archivo propiedad de root demuestra que todo el contenedor se ejecuta como root?
No. Un punto de entrada puede ejecutarse brevemente como root para inicializar un volumen y después eliminar privilegios antes de que se inicie la aplicación.
¿Debo hacer un chown recursivo de todo el volumen?
No antes de identificar el UID previsto, las rutas compartidas, las ACL y la asignación de espacios de nombres. Una reescritura general puede dañar bases de datos, archivos multimedia compartidos o la propiedad de contenedores sin root.
¿Una actualización de imagen puede cambiar el UID de la aplicación?
Sí. Los mantenedores pueden cambiar el usuario de la imagen, reconstruir su base de datos de cuentas, cambiar el nombre de las configuraciones PUID o PGID o añadir una migración de propiedad durante el inicio.
Productos recomendados
Soporte y Consejos
Más para leer
¿Por qué restaurar un volumen de Docker recrea el contenido de los archivos, pero elimina los atributos extendidos?
Un diagnóstico de restauración de volúmenes que abarca el inventario de atributos extendidos, las opciones de tar y Rsync, los espacios de nombres, la...
¿Por qué un contenedor en ejecución mantiene su antiguo límite de memoria después de cambiar el archivo de Compose?
Un diagnóstico del límite de memoria que abarca los cgroups activos, el reinicio frente a la recreación, los campos de Compose, los límites estrictos...
¿Por qué reiniciar un proxy inverso invalida todas las sesiones de una aplicación autoalojada?
Un diagnóstico de pérdida de sesión que abarca el alcance del reinicio, la propiedad de las cookies, la rotación de secretos, las sesiones respaldadas...
