Pourquoi un conteneur commence-t-il à créer des fichiers appartenant à root uniquement après la mise à jour d’une image ?
Un conteneur peut créer des fichiers appartenant à root après la mise à jour d’une image lorsque la nouvelle image modifie son utilisateur d’exécution, son point d’entrée ou sa routine d’initialisation des droits.
Le volume persistant peut rester inchangé tandis que le conteneur de remplacement démarre avec un UID numérique différent ou exécute brièvement une étape d’initialisation en tant que root. Un nouveau point d’entrée peut créer des répertoires manquants, migrer la configuration, réécrire les permissions ou ne plus tenir compte des variables PUID et PGID utilisées par la version précédente. Comparez un fichier antérieur à la mise à jour, un fichier créé au démarrage et un fichier créé par l’application en cours d’exécution avant d’appliquer des changements récursifs de propriétaire.
Prouvez que le propriétaire ne change qu’après le démarrage du conteneur mis à jour
Arrêtez la stack et consignez l’UID numérique, le GID, le mode, les ACL et les horodatages d’un fichier existant et de son répertoire parent. Démarrez une fois le conteneur mis à jour avec les journaux visibles, puis inspectez le même chemin ainsi qu’un fichier nouvellement créé.
Les appels système chown de Linux modifient la propriété numérique. Les éléments décisifs sont donc l’UID et le GID avant et après le démarrage, plutôt que le nom d’utilisateur affiché par l’hôte.
Si le propriétaire est déjà root avant le démarrage, la mise à jour n’en est pas la cause initiale. Recherchez l’opération de copie ou d’extraction de la mise à jour, la restauration d’une sauvegarde ou la commande administrateur qui a écrit les fichiers.
Comparez l’utilisateur de l’image avant et après la mise à jour
Examinez la configuration des anciennes et nouvelles images, l’utilisateur effectif du conteneur, le point d’entrée, la commande et les notes de version. Notez si l’image déclare désormais root, un compte nommé ou un UID numérique différent.
Docker précise que l’instruction USER définit l’identité d’exécution pour les instructions suivantes de l’image ainsi que pour le point d’entrée et la commande du conteneur, lorsqu’aucune surcharge d’exécution ne la remplace.
Une image peut conserver le même nom d’utilisateur applicatif tout en modifiant son UID numérique. Comparez les nombres dans les deux versions de l’image, car les fichiers montés depuis l’hôte stockent une propriété numérique, et non le libellé du nom d’utilisateur de l’image.
Vérifiez si le nouveau point d’entrée exécute un chown récursif
Recherchez dans les journaux de démarrage, les notes de version, les scripts de point d’entrée et les traces de processus les termes chown, réparation des permissions, PUID, PGID, migration d’utilisateur ou initialisation de répertoire. Effectuez le test sur un petit instantané ou un volume jetable.
GNU Coreutils définit chown récursif comme une réécriture de la propriété sur l’arborescence sélectionnée, ce qui peut donner l’impression qu’un volume existant correct a été modifié immédiatement après le démarrage de la nouvelle image.
Ne supprimez pas cette réparation au démarrage sans vérification. Certaines images en dépendent pour les répertoires nouvellement créés. Préférez un indicateur de désactivation documenté, un UID applicatif fixe ou un chemin de données plus restreint lorsque l’image le permet.
Auditez les remplacements de l’utilisateur dans Compose et les variables PUID ou PGID supprimées
Comparez le modèle Compose déployé avant et après la mise à jour, notamment user:, les variables d’environnement, les groupes supplémentaires, les profils, les fichiers de surcharge et les paramètres enregistrés par le gestionnaire de stack.
Kubernetes utilise des identités numériques explicites pour l’exécution et les volumes, ce qui illustre la même limite entre conteneur et hôte : la surcharge d’exécution et la politique de propriété du volume sont deux paramètres distincts qui doivent rester cohérents.
Si l’ancienne image traduisait les variables PUID et PGID, mais que la nouvelle version les a supprimées ou renommées, elles peuvent rester présentes sans contrôler le processus. Vérifiez directement l’UID du processus en cours d’exécution.
Tenez compte de l’exécution rootless et de la correspondance des identifiants des espaces de noms utilisateur
Notez si Docker fonctionne en mode rootful, rootless ou avec une remappage des espaces de noms utilisateur. Comparez l’UID visible dans le conteneur avec le propriétaire visible sur l’hôte pour le même inode.
Red Hat explique que les conteneurs rootless utilisent des plages d’UID et de GID secondaires. Ainsi, root dans le conteneur n’apparaît pas nécessairement comme l’UID 0 sur l’hôte, et une mise à jour peut révéler une correspondance ou un mode d’exécution différent.
Ne modifiez pas récursivement la propriété d’un volume rootless pour lui attribuer root sur l’hôte sans comprendre la correspondance. Cela peut rendre les données inaccessibles à l’identité de conteneur prévue.
Vérifiez si un montage idmapped ou réseau modifie le propriétaire affiché
Déterminez si les données de l’application se trouvent sur un système de fichiers local, un montage idmapped, NFS, SMB, FUSE ou un partage NAS. Consignez les options de montage et comparez la propriété depuis le serveur, l’hôte et le conteneur.
Le modèle de montage idmapped du noyau Linux sépare la propriété du système de fichiers de celle du montage. Ainsi, un même fichier peut apparaître avec des identifiants différents sans réécriture récursive physique de sa propriété.
Si seul le propriétaire affiché change après la mise à jour, vérifiez si l’environnement d’exécution entre désormais dans un autre espace de noms ou une autre correspondance de montage. Corrigez la correspondance plutôt que de réécrire chaque inode.
Rétablissez une identité d’exécution stable et vérifiez la mise à jour suivante
Sauvegardez les métadonnées de propriété, arrêtez l’application, définissez l’UID et le GID numériques prévus, corrigez uniquement les chemins appartenant à l’application, puis redéployez avec une image épinglée et des paramètres utilisateur documentés.
L’article de ZimaSpace sur la propriété des conteneurs après la copie de données d’application traite des causes liées à la copie et à la migration ; cet article se concentre sur un changement introduit par l’image de remplacement.
La réparation est terminée lorsque le démarrage, les écritures de l’application, la recréation du conteneur, le redémarrage de l’hôte et une mise à jour contrôlée de l’image créent tous les fichiers avec l’identité documentée, sans exceptions générales de permissions.
Questions fréquentes
Un fichier appartenant à root prouve-t-il que tout le conteneur s’exécute en tant que root ?
Non. Un point d’entrée peut s’exécuter brièvement en tant que root pour initialiser un volume, puis abandonner ses privilèges avant le démarrage de l’application.
Dois-je modifier récursivement la propriété de l’intégralité du volume ?
Pas avant d’avoir identifié l’UID prévu, les chemins partagés, les ACL et la correspondance des espaces de noms. Une réécriture générale peut endommager les bases de données, les médias partagés ou la propriété des conteneurs rootless.
Une mise à jour d’image peut-elle modifier l’UID de l’application ?
Oui. Les mainteneurs peuvent modifier l’utilisateur de l’image, reconstruire sa base de comptes, renommer les paramètres PUID ou PGID, ou ajouter une migration de propriété au démarrage.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
