Lista kontrolna mapowania użytkowników i grup kontenerów dla udziałów NAS
Bezpieczne podejście polega na traktowaniu sprawdzania mapowania tożsamości numerycznej - od eksportu NAS przez montowanie na hoście po działający proces kontenera - jako sekwencji obserwowalnych etapów, a nie pojedynczego polecenia.
Na hoście kontenerów z systemem Linux, korzystającym z udziałów NAS opartych na SMB lub NFS, praktyczne ryzyko polega na tym, że kontener może widzieć ścieżkę zamontowaną z NAS, ale odczyt lub zapis kończy się błędami uprawnień. Zapisz bieżącą tożsamość i punkt odzyskiwania, zacznij od najmniej inwazyjnego rozróżnienia, zinterpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz przerwij, gdy pamięć masowa stanie się niestabilna lub jedyna możliwa do odzyskania kopia byłaby narażona. Poniższa procedura kończy się dopiero wtedy, gdy pierwotne obciążenie zakończy się powodzeniem albo dowody doprowadzą do granicy eskalacji.
Zidentyfikuj rzeczywistą tożsamość procesu kontenera
Sprawdź dokumentację obrazu, ustawienie Compose user, zmienne środowiskowe, działanie punktu wejścia oraz UID, GID i dodatkowe grupy uruchomionego procesu aplikacji. Zmienne o nazwach PUID i PGID to konwencje stosowane przez obrazy, a nie uniwersalne funkcje Dockera, dlatego potwierdź, że dany obraz je obsługuje.
Przypadek społeczności LinuxServer dotyczący uprawnień kontenera związanych z PUID i PGID pokazuje, że pozornie prawidłowe wartości PUID i PGID nadal mogą pozostawić niedostępny montowany katalog. Potraktuj ten przypadek jako przypomnienie, by sprawdzać działający proces i montowanie, a nie jako dowód, że każdy obraz stosuje tę samą logikę inicjalizacji.
Zapisz wartości numeryczne za pomocą id wewnątrz kontenera i na hoście. Przerwij, jeśli aplikacja działa jako root wyłącznie dlatego, że wcześniej wystąpiły problemy z uprawnieniami; dostęp roota maskuje błąd mapowania i zwiększa skutki przejęcia usługi.
Prześledź własność od NAS do montowania na hoście
Na NAS sprawdź numerycznego właściciela, grupę, tryb, ACL i domyślną ACL docelowego katalogu. Na hoście kontenera sprawdź te same zamontowane obiekty i porównaj wartości numeryczne. Jeśli nazwy się różnią, ale liczby są takie same, etykiety mają znaczenie wyłącznie kosmetyczne; jeśli liczby się różnią, ścieżka autoryzacji rzeczywiście jest inna.
W przypadku NFS uwzględnij opcje eksportu, wersję NFS, mapowanie identyfikatorów, root squashing oraz tożsamość klienta podczas montowania. W przypadku SMB uwzględnij dane uwierzytelniające montowania, tożsamość mapowaną po stronie serwera, opcje prezentacji uid lub gid oraz to, czy używane są rozszerzenia uniksowe lub translacja ACL.
Nie zmieniaj jednocześnie ACL serwera i opcji montowania klienta. Etap kończy się powodzeniem, gdy jeden plik testowy ma znanego właściciela numerycznego, a host widzi stabilne mapowanie po odmontowaniu, ponownym zamontowaniu i ponownym uruchomieniu.
Przetestuj montowanie wiązane i dodatkowe grupy
Potwierdź, że ścieżka źródłowa kontenera wskazuje oczekiwane montowanie na hoście, a nie pusty lokalny katalog utworzony przed zamontowaniem udziału sieciowego. Sprawdź montowanie środowiska uruchomieniowego, a następnie w nietrwałym podkatalogu przetestuj jako użytkownik aplikacji wyświetlanie zawartości, odczyt, tworzenie, zmianę nazwy i usuwanie.
Przypadek z Server Fault opisuje niezgodność uprawnień ACL w NFS, nawet gdy wpisy właściciela i ACL wydają się zgodne, pokazując, dlaczego należy sprawdzić maskę ACL, mapowanie serwera i efektywną tożsamość. Zapisz wynik getfacl zarówno dla katalogu, jak i utworzonego pliku.
Jeśli zamierzony jest dostęp grupowy, dodaj obsługiwaną dodatkową grupę numeryczną i utwórz kontener ponownie, ponieważ grupy procesów są ustalane podczas uruchamiania. Skorzystaj z poradnika ZimaSpace dotyczącego diagnozowania pustej ścieżki w kontenerze, gdy aplikacja uruchamia się ze wskazaniem na pustą ścieżkę; jest to problem kolejności montowania, a nie problem ACL.
Zastosuj najwęższą poprawkę tożsamości i przetestuj ponownie
Preferuj dopasowanie obsługiwanego przez aplikację UID, GID lub dodatkowej grupy do zasad NAS. Gdy wiele usług współpracuje, użyj wspólnej grupy i dziedziczonej ACL. Unikaj uprawnień do zapisu dla wszystkich, rekurencyjnych zmian własności w niepowiązanych zbiorach danych oraz uprzywilejowanych kontenerów jako skrótów.
Utwórz kontener ponownie, ponownie zamontuj udział, jeśli zmieniły się opcje mapowania, i powtórz te same operacje. Raz uruchom ponownie hosta, aby zweryfikować, że kolejność montowania i tożsamość numeryczna są zachowane po uruchomieniu systemu. Potwierdź, że nowo utworzone pliki nadal można zapisywać z uprawnieniami przeznaczonymi dla użytkowników, bez przyznawania kontenerowi niepotrzebnych praw.
Zamknij listę kontrolną, gdy aplikacja pomyślnie obsłuży pierwotne obciążenie, operacje odrzucone nadal pozostają odrzucone, a własność jest stabilna po ponownym uruchomieniu. Eskaluj problem, jeśli przestrzenie nazw użytkowników, mapowania bez roota lub usługi tożsamości NAS przepisują identyfikatory w sposób, którego wybrany obraz nie jest w stanie obsłużyć.
Polecane produkty
Wsparcie i wskazówki
Więcej do przeczytania
Lista kontrolna migracji NFS dla przemianowanych zbiorów danych i stabilnych uchwytów plików
Załóż, że deskryptory plików mogą się zmienić, gdy zmieni się tożsamość pamięci masowej. Wstrzymaj klientów, celowo przełącz eksport, zamontuj ponownie i zweryfikuj otwarte oraz...
Przewodnik rozwiązywania problemów z klientem SMB dla systemów Windows, macOS i Linux
Używaj tego samego serwera, konta, udziału i operacji na plikach na każdym kliencie, aby nie mieszać problemów z wykrywaniem, poświadczeniami, zasadami ani pamięcią masową.
Lista kontrolna rotacji sekretów serwera domowego dla aplikacji, baz danych i kopii zapasowych
Potraktuj rotację jak migrację zależności: zmapuj każdego konsumenta, w miarę możliwości nakładaj dane uwierzytelniające, zweryfikuj nową wartość, a następnie unieważnij starą i przetestuj odzyskiwanie.
