Varför börjar en container skapa filer som ägs av root först efter en imageuppdatering?

En container kan skapa root-ägda filer efter en bilduppdatering när den nya avbilden ändrar sin körningsanvändare, sin startpunkt eller sin rutin för ägarskap vid uppstart.

Den beständiga volymen kan förbli oförändrad medan ersättningscontainern startar med ett annat numeriskt UID eller tillfälligt kör ett initieringssteg som root. En ny startpunkt kan skapa saknade kataloger, migrera konfiguration, skriva om behörigheter eller sluta använda PUID- och PGID-variabler som användes i den tidigare versionen. Jämför en fil från före uppdateringen, en fil som skapats vid uppstart och en fil som skapats av den körande applikationen innan du ändrar ägarskapet rekursivt.

Bevisa att ägarskapet ändras först när den uppdaterade containern startar

Stoppa stacken och registrera numeriskt UID, GID, läge, ACL:er och tidsstämplar för en befintlig fil och dess överordnade katalog. Starta den uppdaterade containern en gång med synliga loggar och inspektera sedan samma sökväg samt en nyskapad fil.

Linux chown-systemanrop ändrar numeriskt ägarskap, så de avgörande bevisen är UID och GID före och efter uppstart, inte användarnamnet som värddatorn visar.

Om ägarskapet redan är root före uppstart är uppdateringen inte den första orsaken. Undersök uppdateringskopieringen, uppackningen, återställningen från säkerhetskopian eller administratörskommandot som skrev filerna.

Jämför avbildens användare före och efter uppdateringen

Inspektera konfigurationen för den gamla och den nya avbilden, den effektiva containeranvändaren, startpunkten, kommandot och versionsinformationen. Registrera om avbilden nu deklarerar root, ett namngivet konto eller ett annat numeriskt UID.

Docker dokumenterar att USER-instruktionen anger körningsidentiteten för senare instruktioner i avbilden samt för containerns startpunkt och kommando när ingen körningsöversstyrning ersätter den.

En avbild kan behålla samma användarnamn för applikationen men ändra sitt numeriska UID. Jämför numren i båda avbildsversionerna, eftersom värdmonterade filer lagrar numeriskt ägarskap och inte avbildens etikett för användarnamn.

Kontrollera om den nya startpunkten kör en rekursiv chown

Sök i startloggar, versionsinformation, startpunktsskript och processtrådar efter chown, behörighetsreparation, PUID, PGID, användarmigrering eller kataloginitiering. Testa på en liten ögonblicksbild eller en tillfällig volym.

GNU Coreutils definierar rekursiv chown som en omskrivning av ägarskapet i det valda katalogträdet, vilket kan få en korrekt befintlig volym att verka ändras omedelbart efter att den nya avbilden startar.

Ta inte bort startrutinen för reparation utan vidare. Vissa avbilder är beroende av den för nyskapade kataloger. Föredra en dokumenterad flagga för att hoppa över steget, ett fast applikations-UID eller en snävare datasökväg när avbilden stöder det.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Granska användaröversstyrningar i Compose och borttagna PUID- eller PGID-variabler

Jämför den distribuerade Compose-modellen före och efter uppdateringen, inklusive user:, miljövariabler, kompletterande grupper, profiler, översstyrningsfiler och de sparade inställningarna i stackhanteraren.

Kubernetes använder explicit numeriska körnings- och volymidentiteter, vilket illustrerar samma containergräns: en körningsöversstyrning och en policy för volymägarskap är separata inställningar som måste förbli samordnade.

Om den gamla avbilden översatte PUID- och PGID-variabler men den nya versionen tog bort eller bytte namn på dem kan variablerna finnas kvar utan att längre styra processen. Verifiera det körande UID:t direkt.

Ta hänsyn till rootless och mappning av användarnamnrymder

Registrera om Docker körs rootful, rootless eller med ommappning av användarnamnrymder. Jämför det UID som syns i containern med ägaren som värddatorn visar för samma inode.

Red Hat förklarar att rootless-containrar använder underordnade UID- och GID-intervall, så root i containern visas inte nödvändigtvis som UID 0 på värddatorn, och en uppdatering kan synliggöra en ändrad mappning eller körningsmetod.

Ändra inte ägarskapet rekursivt på en rootless-volym till root på värddatorn utan att förstå mappningen. Det kan göra data otillgänglig för den avsedda containeridentiteten.

Kontrollera om en idmapped- eller nätverksmontering ändrar den synliga ägaren

Identifiera om appens data finns på ett lokalt filsystem, en idmapped-montering, NFS, SMB, FUSE eller en NAS-delning. Registrera monteringsalternativen och jämför ägarskapet från servern, värddatorn och containern.

Linuxkärnans modell för idmapped-monteringar skiljer filsystemets ägarskap från monteringens ägarskap, så samma fil kan visas med olika ID:n utan att något fysiskt rekursivt ägarskapsbyte har skett.

Om endast den visade ägaren ändras efter uppdateringen ska du kontrollera om körningen nu går in i en annan namnrymd eller monteringsmappning. Reparera mappningen i stället för att skriva om varje inode.

Återställ en stabil körningsidentitet och verifiera nästa uppdatering

Säkerhetskopiera metadata för ägarskap, stoppa appen, definiera avsett numeriskt UID och GID, korrigera endast de appspecifika sökvägarna och distribuera på nytt med en fixerad avbild samt dokumenterade användarinställningar.

ZimaSpaces artikel om containerägarskap efter kopiering av appdata behandlar orsaker vid kopiering och migrering; den här artikeln isolerar en ändring som introducerats av ersättningsavbilden.

Reparationen är klar när uppstart, skrivningar från applikationen, återskapande av containern, omstart av värddatorn och en kontrollerad bilduppdatering alla skapar filer under den dokumenterade identiteten utan omfattande undantag från behörigheterna.

Vanliga frågor

Bevisar en root-ägd fil att hela containern körs som root?

Nej. En startpunkt kan köras kortvarigt som root för att initiera en volym och sedan sänka sina privilegier innan applikationen startar.

Bör jag ändra ägarskapet rekursivt för hela volymen?

Inte innan du har identifierat avsett UID, delade sökvägar, ACL:er och namnrymdsmappning. En omfattande omskrivning kan skada databaser, delade medier eller ägarskapet för rootless-containrar.

Kan en bilduppdatering ändra applikationens UID?

Ja. Underhållare kan ändra avbildens användare, bygga om dess kontodatabas, byta namn på PUID- eller PGID-inställningar eller lägga till en migrering av ägarskapet vid uppstart.