Czy kontener bez uprawnień roota może uzyskać dostęp do urządzenia USB na domowym serwerze?

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.

Czasami. Użytkownik uruchamiający kontener musi już mieć uprawnienia na hoście, a środowisko uruchomieniowe musi mapować urządzenie bez wymagania możliwości niedostępnych w przestrzeni nazw użytkownika.

Staje się to rzeczywistym problemem zgodności, gdy bezrootowy kontener multimedialny, radiowy, UPS lub automatyzacji potrzebuje stabilnej ścieżki /dev, która może zniknąć i pojawić się ponownie po odłączeniu urządzenia lub ponownym uruchomieniu. Zacznij od tymczasowej ścieżki lub konta, zachowaj poprzedni działający stan i oceniaj projekt na podstawie pierwotnego obciążenia, a nie jednorazowego testu połączenia.

Ustal granicę uprawnień i tożsamości dla bezrootowego dostępu do urządzeń USB

Obsługiwana ścieżka obejmuje dostęp przez grupę lub ACL na hoście oraz jawnie mapowane urządzenie. Alternatywna ścieżka to brak uprawnień na hoście, niestabilna tożsamość urządzenia albo uprzywilejowana operacja blokowana przez izolację bezrootową. Zapisz wersje, tożsamości, adresy, ścieżki montowania, uprawnienia i bieżący obserwowalny stan przed zmianą którejkolwiek ze ścieżek.

Odpowiednie bezrootowe przestrzenie nazw użytkownika definiują pierwszą granicę zgodności. Wykorzystaj je do ograniczenia zakresu twierdzenia, a następnie zweryfikuj to samo zachowanie na tym konkretnym serwerze domowym, zamiast uznawać udokumentowaną funkcję za dowód, że cały projekt działa.

Przed testem zapisz regułę decyzyjną: powodzenie musi oznaczać, że proces otwiera właściwe urządzenie po ponownym utworzeniu kontenera i podłączeniu urządzenia bez szerokiego trybu uprzywilejowanego; niepowodzenie obejmuje odmowę dostępu, zmianę ścieżki lub sytuację, w której operacja sterownika nadal wymaga uprawnienia na poziomie hosta. Zapobiega to błędnemu uznaniu częściowego połączenia lub poprawnego zakończenia polecenia za zgodność całego rozwiązania.

Przetestuj dostęp bez zwiększania uprawnień

Zastosuj jeden kontrolowany wyróżnik: zidentyfikuj urządzenie na podstawie stabilnych atrybutów udev, zweryfikuj dostęp na hoście jako użytkownik bezrootowy, zmapuj urządzenie, a następnie odłącz i ponownie podłącz tymczasowe urządzenie. Nie zmieniaj klienta, obciążenia, zestawu plików, konta ani czasu, aby zmieniony komponent był jedynym prawdopodobnym wyjaśnieniem.

Użyj mapowań urządzeń Podmana, aby wybrać drugą obserwację istotną dla tej ścieżki. Rejestruj obie strony transakcji: resolver lub trasę, wynegocjowany protokół, tożsamość procesu, kod wyjścia, opóźnienie, przesłane bajty i każde zdarzenie odzyskiwania.

Powtórz test po zdarzeniu cyklu życia wymienionym w tytule — ponownym utworzeniu, ponownym podłączeniu, ponownym zamontowaniu, restarcie, przełączeniu awaryjnym lub zmianie klienta. Projekt, który działa tylko wtedy, gdy stare gniazda, pamięci podręczne lub dane uwierzytelniające pozostają aktywne, nie przeszedł testu.

id
stat /dev/serial/by-id/*
podman run --device /dev/serial/by-id/DEVICE IMAGE

Odróżnij obsługiwany dostęp od częściowego obejścia

PASS: proces otwiera właściwe urządzenie po ponownym utworzeniu kontenera i podłączeniu urządzenia bez szerokiego trybu uprzywilejowanego. Zapisz dokładne wersje i topologię, które doprowadziły do tego stanu, ponieważ wniosek dotyczy tych warunków, a nie każdej implementacji protokołu.

FAIL: dostęp jest odrzucany, ścieżka się zmienia albo operacja sterownika nadal wymaga uprawnienia na poziomie hosta. Sprawdź współdzielone zależności, takie jak DNS, MTU, tożsamość, stan zapory, opóźnienia pamięci masowej i buforowane sesje, zanim przypiszesz odpowiedzialność którejkolwiek z głównych ścieżek.

EXCEPTION: usuń mapowanie urządzenia, przywróć poprzedni stan ACL lub grupy i użyj pomocniczego procesu na hoście o ściśle ograniczonym zakresie tylko wtedy, gdy operacja nie może działać bezrootowo. Nie zwiększaj uprawnień, nie usuwaj danych źródłowych, nie osłabiaj bezpieczeństwa transportu ani nie wymieniaj działającej pamięci masowej, dopóki powtarzalna obserwacja nie wskaże, która granica zawiodła.

Potwierdź trwałość po ponownym podłączeniu lub restarcie

Zastosuj wyłącznie działanie odpowiadające zaobserwowanej ścieżce, a następnie ponownie uruchom pierwotne obciążenie. Zachowaj projekt tylko wtedy, gdy proces otwiera właściwe urządzenie po ponownym utworzeniu kontenera i podłączeniu urządzenia bez szerokiego trybu uprzywilejowanego w dwóch odpowiednich cyklach życia oraz przy oczekiwanym równoległym obciążeniu.

Użyj trwałego przekazywania urządzeń, aby zweryfikować najbardziej zbliżony zależny przepływ pracy. Jego zachowanie pod względem dostępu, czasu i odzyskiwania musi pozostać niezmienione, gdy nowy projekt jest aktywny.

Zatrzymaj się i wróć do zapisanego stanu, jeśli dostęp jest odrzucany, ścieżka się zmienia albo operacja sterownika nadal wymaga uprawnienia na poziomie hosta. Eskaluj problem, podając znaczniki czasu, dokładne wersje, dowody dotyczące trasy lub montowania oraz najmniejszy przypadek odtwarzający problem, zamiast dodawać kolejne obejście.

Porównaj wynik z mapowaniem tożsamości kontenera, aby ryzyko nie zostało jedynie przeniesione do innej warstwy sieci, tożsamości, kopii zapasowych lub pamięci masowej.

W przypadku bezrootowego dostępu do urządzeń USB właściwa odpowiedź brzmi zatem tak, jak początkowa ocena — a nie bezwarunkowe „tak”. Obserwowalny stan powodzenia jest linią akceptacji; stan niepowodzenia jest linią wycofania zmian.

FAQ

Czy dodanie użytkownika do grupy dialout rozwiązuje każdy przypadek USB?

Nie. Pomaga w przypadku urządzeń szeregowych tylko wtedy, gdy węzeł urządzenia korzysta z tej grupy i nie jest wymagane dodatkowe uprzywilejowane wywołanie ioctl.

Czy kontener bezrootowy może automatycznie wykrywać podłączane urządzenia?

Tylko jeśli zmapowana ścieżka i zachowanie środowiska uruchomieniowego przetrwają zdarzenie dotyczące urządzenia; przetestuj cykl odłączenia i ponownego podłączenia.

Czy zamiast tego kontener powinien działać w trybie uprzywilejowanym?

Nie w pierwszej kolejności. Udowodnij, która dokładnie operacja jest odrzucana, a następnie nadaj najmniejsze uprawnienie po stronie hosta, które ją obsłuży.

Wsparcie i wskazówki

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.