Waarom begint een container pas na een image-update bestanden aan te maken die eigendom zijn van root?
Een container kan na een image-update bestanden aanmaken waarvan root de eigenaar is, wanneer het nieuwe image de runtimegebruiker, het entrypoint of de routine voor eigendomsbeheer bij het opstarten wijzigt.
Het persistente volume kan ongewijzigd blijven, terwijl de vervangende container start met een andere numerieke UID of kortstondig een initialisatiestap als root uitvoert. Een nieuw entrypoint kan ontbrekende mappen aanmaken, configuratie migreren, machtigingen opnieuw instellen of de PUID- en PGID-variabelen die door de vorige release werden gebruikt niet langer respecteren. Vergelijk één bestand van vóór de update, één bestand dat bij het opstarten is aangemaakt en één bestand dat door de actieve applicatie is aangemaakt voordat je eigendom recursief wijzigt.
Bewijs dat het eigendom pas verandert nadat de bijgewerkte container is gestart
Stop de stack en noteer de numerieke UID, GID, modus, ACL's en tijdstempels van één bestaand bestand en de bovenliggende map. Start de bijgewerkte container één keer met zichtbare logs en controleer daarna hetzelfde pad en één nieuw aangemaakt bestand.
De Linux-systeemaanroepen van chown wijzigen numeriek eigendom. Het doorslaggevende bewijs zijn daarom de UID en GID vóór en na het opstarten, niet de gebruikersnaam die de host weergeeft.
Als het eigendom al vóór het opstarten root is, is de update niet de eerste oorzaak. Onderzoek dan de updatekopie, het uitpakken, het terugzetten van een back-up of de beheeropdracht waarmee de bestanden zijn geschreven.
Vergelijk de imagegebruiker vóór en na de update
Controleer de configuratie van het oude en nieuwe image, de effectieve containergebruiker, het entrypoint, de opdracht en de release-opmerkingen. Noteer of het image nu root, een benoemd account of een andere numerieke UID gebruikt.
Docker documenteert dat de USER-instructie de runtime-identiteit instelt voor latere image-instructies en voor het entrypoint en de opdracht van de container, wanneer een runtime-override deze niet vervangt.
Een image kan dezelfde gebruikersnaam voor de applicatie behouden en toch de numerieke UID wijzigen. Vergelijk de nummers in beide imageversies, omdat bestanden die op de host zijn aangekoppeld numeriek eigendom opslaan en niet het gebruikersnaaml abel van het image.
Controleer of het nieuwe entrypoint een recursieve chown uitvoert
Zoek in opstartlogs, release-opmerkingen, entrypointscripts en procestraceringen naar chown, herstel van machtigingen, PUID, PGID, gebruikersmigratie of initialisatie van mappen. Test dit op een kleine momentopname of een wegwerpvolume.
GNU Coreutils definieert recursieve chown als een herschrijving van eigendom voor de geselecteerde mappenstructuur. Daardoor kan een bestaand, correct volume direct na het starten van het nieuwe image veranderd lijken.
Verwijder het herstel bij het opstarten niet zomaar. Sommige images zijn hiervan afhankelijk voor nieuw aangemaakte mappen. Gebruik bij voorkeur een gedocumenteerde vlag om dit over te slaan, een vaste applicatie-UID of een smaller datapad wanneer het image dit ondersteunt.
Controleer Compose-overschrijvingen voor de gebruiker en verwijderde PUID- of PGID-variabelen
Vergelijk het ingezette Compose-model vóór en na de update, inclusief user:, omgevingsvariabelen, aanvullende groepen, profielen, overridebestanden en de opgeslagen instellingen van de stackbeheerder.
Kubernetes gebruikt expliciete numerieke runtime- en volume-identiteiten. Dit illustreert dezelfde containergrens: een runtime-override en een beleid voor volume-eigendom zijn afzonderlijke instellingen die op elkaar afgestemd moeten blijven.
Als het oude image PUID- en PGID-variabelen vertaalde, maar de nieuwe release deze heeft verwijderd of hernoemd, kunnen de variabelen aanwezig blijven zonder het proces nog te besturen. Controleer de actieve UID rechtstreeks.
Houd rekening met rootless containers en ID-toewijzing via gebruikersnaamruimten
Noteer of Docker rootful, rootless of met gebruikersnaamruimte-remapping draait. Vergelijk de UID die in de container zichtbaar is met de eigenaar van dezelfde inode zoals die op de host zichtbaar is.
Red Hat legt uit dat rootless containers onderliggende UID- en GID-bereiken gebruiken. Root in de container verschijnt daardoor niet noodzakelijk als host-UID 0, en een update kan een gewijzigde toewijzing of runtime-modus zichtbaar maken.
Voer geen recursieve chown uit op een rootless volume om dit aan host-root toe te wijzen zonder de toewijzing te begrijpen. Daardoor kan de data ontoegankelijk worden voor de bedoelde containeridentiteit.
Controleer of een idmapped- of netwerkvolume de zichtbare eigenaar verandert
Stel vast of de applicatiedata op een lokaal bestandssysteem, idmapped volume, NFS-, SMB-, FUSE- of NAS-share staat. Noteer de mountopties en vergelijk het eigendom vanaf de server, de host en de container.
Het idmapped-volumemodel van de Linux-kernel scheidt bestandssysteemeigendom van volume-eigendom. Hetzelfde bestand kan daardoor onder verschillende ID's verschijnen zonder dat het fysieke eigendom recursief is herschreven.
Als alleen de weergegeven eigenaar na de update verandert, controleer dan of de runtime nu een andere naamruimte- of volumetoewijzing gebruikt. Herstel de toewijzing in plaats van elke inode opnieuw te wijzigen.
Herstel een stabiele runtime-identiteit en controleer de volgende update
Maak een back-up van de metagegevens voor eigendom, stop de applicatie, definieer de beoogde numerieke UID en GID, corrigeer alleen de paden waarvan de applicatie eigenaar is en implementeer opnieuw met een vastgezet image en gedocumenteerde gebruikersinstellingen.
Het ZimaSpace-artikel over eigendom van containers na het kopiëren van applicatiedata behandelt oorzaken bij kopiëren en migreren; dit artikel richt zich op een wijziging die door het vervangende image is geïntroduceerd.
De reparatie is voltooid wanneer het opstarten, schrijven door de applicatie, opnieuw aanmaken van de container, herstarten van de host en een gecontroleerde image-update allemaal bestanden aanmaken met de gedocumenteerde identiteit, zonder brede uitzonderingen voor machtigingen.
Veelgestelde vragen
Bewijst een bestand waarvan root de eigenaar is dat de hele container als root draait?
Nee. Een entrypoint kan kortstondig als root draaien om een volume te initialiseren en daarna privileges laten vallen voordat de applicatie start.
Moet ik het hele volume recursief chownen?
Niet voordat je de beoogde UID, gedeelde paden, ACL's en naamruimtetoewijzing hebt vastgesteld. Een brede herschrijving kan databases, gedeelde media of eigendom van rootless containers beschadigen.
Kan een image-update de UID van de applicatie wijzigen?
Ja. Onderhouders kunnen de gebruiker van het image wijzigen, de accountdatabase opnieuw opbouwen, PUID- of PGID-instellingen hernoemen of een migratie van eigendom bij het opstarten toevoegen.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Waarom herstelt een Docker-volume de bestandsinhoud, maar gaan uitgebreide bestandskenmerken verloren?
Een diagnose van volumeterugzetting met een inventaris van xattrs, tar- en Rsync-opties, naamruimten, ondersteuning voor bestemmingen, machtigingen, labels, app-metagegevens en tests.
Waarom behoudt een actieve container zijn oude geheugenlimiet nadat het Compose-bestand is gewijzigd?
Een diagnose van geheugenlimieten met aandacht voor actieve cgroups, herstarten versus opnieuw aanmaken, Compose-velden, harde en zachte limieten, bovenliggende scopes, swap en runtime-heaps.
Waarom maakt het herstarten van een reverse proxy elke sessie voor één zelfgehoste app ongeldig?
Een diagnose van sessieverlies met aandacht voor de reikwijdte van herstarts, cookie-eigenaarschap, geheimenrotatie, cachegestuurde sessies, sticky routing, authenticatiegateways en herstel.
