Dlaczego kontener zaczyna tworzyć pliki należące do użytkownika root dopiero po aktualizacji obrazu?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Does a Container Start Creating Root-Owned Files Only After an Image Update? - Zima Store Online

Kontener może tworzyć pliki należące do roota po aktualizacji obrazu, gdy nowy obraz zmieni użytkownika uruchomieniowego, punkt wejścia lub procedurę ustawiania własności podczas startu.

Trwały wolumin może pozostać niezmieniony, podczas gdy zastępczy kontener uruchamia się z innym numerycznym UID albo na krótko wykonuje etap inicjalizacji jako root. Nowy punkt wejścia może tworzyć brakujące katalogi, migrować konfigurację, ponownie ustawiać uprawnienia lub przestać uwzględniać zmienne PUID i PGID używane przez poprzednie wydanie. Przed zastosowaniem rekurencyjnych zmian własności porównaj jeden plik sprzed aktualizacji, jeden plik utworzony podczas startu oraz jeden plik utworzony przez działającą aplikację.

Udowodnij, że własność zmienia się dopiero po uruchomieniu zaktualizowanego kontenera

Zatrzymaj stos i zapisz numeryczne UID, GID, tryb, listy ACL oraz znaczniki czasu dla jednego istniejącego pliku i jego katalogu nadrzędnego. Uruchom zaktualizowany kontener, obserwując logi, a następnie sprawdź tę samą ścieżkę oraz jeden nowo utworzony plik.

Wywołania systemowe chown systemu Linux zmieniają własność numeryczną, dlatego decydującym dowodem jest UID i GID przed uruchomieniem oraz po nim, a nie nazwa użytkownika wyświetlana przez hosta.

Jeśli własność już przed uruchomieniem wskazuje na roota, aktualizacja nie jest pierwszą przyczyną. Zbadaj proces kopiowania podczas aktualizacji, rozpakowywania, przywracania kopii zapasowej lub polecenie administratora, które zapisało pliki.

Porównaj użytkownika obrazu przed i po aktualizacji

Sprawdź konfigurację starego i nowego obrazu, efektywnego użytkownika kontenera, punkt wejścia, polecenie oraz informacje o wydaniu. Zapisz, czy obraz deklaruje teraz roota, nazwane konto czy inny numeryczny UID.

Docker dokumentuje, że instrukcja USER ustawia tożsamość uruchomieniową dla kolejnych instrukcji obrazu oraz punktu wejścia i polecenia kontenera, jeśli nie zastąpi jej ustawienie uruchomieniowe.

Obraz może zachować tę samą nazwę użytkownika aplikacji, a jednocześnie zmienić jego numeryczny UID. Porównaj numery w obu wersjach obrazu, ponieważ pliki montowane z hosta przechowują własność numeryczną, a nie etykietę nazwy użytkownika z obrazu.

Sprawdź, czy nowy punkt wejścia wykonuje rekurencyjne chown

Przeszukaj logi startowe, informacje o wydaniu, skrypty punktu wejścia i ślady procesów pod kątem chown, naprawy uprawnień, PUID, PGID, migracji użytkownika lub inicjalizacji katalogów. Przetestuj zmiany na małej migawce albo tymczasowym woluminie.

GNU Coreutils definiuje rekurencyjne chown jako przepisanie własności w wybranym drzewie katalogów, przez co prawidłowy istniejący wolumin może wyglądać tak, jakby został zmieniony natychmiast po uruchomieniu nowego obrazu.

Nie usuwaj bez namysłu mechanizmu naprawczego uruchamianego podczas startu. Niektóre obrazy potrzebują go do obsługi nowo tworzonych katalogów. Jeśli obraz to umożliwia, wybierz udokumentowaną opcję pominięcia, stały UID aplikacji lub węższą ścieżkę danych.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Sprawdź zastąpienia użytkownika w Compose oraz usunięte zmienne PUID lub PGID

Porównaj wdrożony model Compose sprzed i po aktualizacji, w tym user:, zmienne środowiskowe, dodatkowe grupy, profile, pliki zastępujące oraz ustawienia zapisane przez menedżera stosu.

Kubernetes korzysta z jawnie określonych numerycznych tożsamości uruchomieniowych i woluminów, pokazując tę samą granicę kontenera: zastąpienie ustawień uruchomieniowych i zasady własności woluminu to odrębne ustawienia, które muszą pozostać zgodne.

Jeśli stary obraz tłumaczył zmienne PUID i PGID, a nowe wydanie je usunęło lub zmieniło ich nazwy, zmienne mogą nadal być obecne, ale nie sterować już procesem. Zweryfikuj bezpośrednio UID działającego procesu.

Uwzględnij tryb rootless i mapowanie identyfikatorów przestrzeni użytkownika

Zapisz, czy Docker działa w trybie rootful, rootless czy z mapowaniem przestrzeni użytkownika. Porównaj UID widoczny w kontenerze z właścicielem tego samego i-węzła widocznym na hoście.

Red Hat wyjaśnia, że kontenery rootless korzystają z podrzędnych zakresów UID i GID, dlatego root kontenera nie musi być widoczny jako UID 0 na hoście, a aktualizacja może ujawnić zmienione mapowanie lub tryb uruchomieniowy.

Nie wykonuj rekurencyjnego chown woluminu rootless na rzecz roota hosta bez zrozumienia mapowania. Może to uniemożliwić dostęp do danych zamierzonej tożsamości kontenera.

Sprawdź, czy montowanie idmap lub sieciowe zmienia widocznego właściciela

Ustal, czy dane aplikacji znajdują się na lokalnym systemie plików, montowaniu idmap, udziale NFS, SMB, FUSE lub NAS. Zapisz opcje montowania i porównaj własność z poziomu serwera, hosta oraz kontenera.

Model montowania idmap w jądrze Linux oddziela własność systemu plików od własności montowania, dlatego ten sam plik może pojawiać się pod różnymi identyfikatorami bez fizycznego, rekurencyjnego przepisywania własności.

Jeśli po aktualizacji zmienia się tylko wyświetlany właściciel, sprawdź, czy środowisko uruchomieniowe nie korzysta teraz z innej przestrzeni nazw lub mapowania montowania. Napraw mapowanie zamiast przepisywać każdy i-węzeł.

Przywróć stabilną tożsamość uruchomieniową i zweryfikuj kolejną aktualizację

Utwórz kopię metadanych własności, zatrzymaj aplikację, określ docelowy numeryczny UID i GID, popraw wyłącznie ścieżki należące do aplikacji oraz wdroż ponownie przypięty obraz z udokumentowanymi ustawieniami użytkownika.

Artykuł ZimaSpace dotyczący własności kontenera po skopiowaniu danych aplikacji opisuje przyczyny związane z kopiowaniem i migracją; ten artykuł skupia się na zmianie wprowadzonej przez zastępczy obraz.

Naprawa jest zakończona, gdy podczas uruchamiania, zapisu przez aplikację, odtwarzania kontenera, ponownego uruchomienia hosta oraz kontrolowanej aktualizacji obrazu wszystkie pliki są tworzone z udokumentowaną tożsamością, bez szerokich wyjątków dotyczących uprawnień.

Często zadawane pytania

Czy plik należący do roota dowodzi, że cały kontener działa jako root?

Nie. Punkt wejścia może przez krótki czas działać jako root, aby zainicjalizować wolumin, a następnie obniżyć uprawnienia przed uruchomieniem aplikacji.

Czy należy wykonać rekurencyjne chown na całym woluminie?

Nie, dopóki nie określisz docelowego UID, współdzielonych ścieżek, list ACL i mapowania przestrzeni nazw. Szerokie przepisanie własności może uszkodzić bazy danych, współdzielone multimedia lub własność kontenera rootless.

Czy aktualizacja obrazu może zmienić UID aplikacji?

Tak. Opiekunowie obrazu mogą zmienić użytkownika obrazu, przebudować bazę jego kont, zmienić nazwy ustawień PUID lub PGID albo dodać migrację własności uruchamianą podczas startu.