Chrome pod Dockerem: CAP_SYS_ADMIN czy uprzywilejowany? [Zamknięte]

11

Używam chromeedriver + chrome wewnątrz Docker w moim środowisku testowym.

Wszystko działało dobrze do ostatniej aktualizacji CoreOS.

Są to wersje, które wydają się działać:

VERSION=1185.5.0
VERSION_ID=1185.5.0
BUILD_ID=2016-12-07-0937

A to nowsza wersja, która powoduje, że Chrome coredump:

VERSION=1235.4.0
VERSION_ID=1235.4.0
BUILD_ID=2017-01-04-0450

Patrząc na zmiany, wygląda na to, że doker został zaktualizowany z 1.11.x do 1.12.x, co spowodowało przerwanie setns()połączenia wewnątrz kontenera. setns()jest używany przez Chrome do tworzenia przestrzeni nazw.

Oto przykładowe wyniki:

jsosic-coreos-test-20161207 ~ # docker --version
Docker version 1.11.2, build bac3bae

Z wnętrza jednego pojemnika na tym pudełku:

[root@2939f21ecfaa /]# /opt/google/chrome/google-chrome
[57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display:

Oto jak załamała się nowa wersja:

jsosic-coreos-test-2017-01-04 ~ # docker --version
Docker version 1.12.3, build 34a2ead

[root@13ab34c36c82 /]# /opt/google/chrome/chrome
Failed to move to new namespace: PID namespaces supported,
  Network namespace supported,
  but failed: errno = Operation not permitted
Aborted (core dumped)

Dowiedziałem się, że jeśli uruchomię kontener z jednym --cap-add=SYS_ADMINlub --privileged- Chrome działa zgodnie z oczekiwaniami.

Jaka jest różnica między tymi dwoma przełącznikami? Jakie możliwości są włączone --privileged?

Czy mogę wpuszczać setns()do pojemnika bez narażania bezpieczeństwa?

permissions docker chrome namespaces Jakov Sosic
źródło
Dzięki za to. Zrobiłem problem, używając dużej ilości twoich rzeczy: github.com/docker/for-linux/issues/496 Myślę, że powinno to zostać naprawione
Merc
Jestem prawie 2 lata spóźniony, ale w powyższym bilecie jest o wiele lepsze i bezpieczniejsze rozwiązanie, jeśli nadal jesteś zainteresowany.
Merc
Jeśli oryginalny plakat nie zaktualizuje odpowiedzi (wydaje się, że wcale nie jest aktywny na SO), daj mi znać, czy będziesz w stanie zaakceptować inny. Zmarnowałem na to godziny, mogę sobie tylko wyobrazić, ile godzin uratujemy innych ludzi.
Merc

Odpowiedzi:

7

AFAICS, dokumentacja sugeruje przyznanie możliwości potrzebnych dla kontenera, zamiast używania --privilegedprzełącznika. Wydaje się, że działanie w trybie uprzywilejowanym zapewnia kontenerowi wszystkie możliwości (dokładnie te, które są wymienione w pierwszym adresie URL, pod warunkiem, że dokumenty są aktualne).

Krótko mówiąc, powiedziałbym, że --cap-add=SYS_ADMINzapewnia mniejszy podzbiór możliwości kontenerowi w porównaniu do --privilegedprzełącznika. Zdarzają się, że przykłady w dokumentacji Dockera (pierwszy adres URL) wydają się preferować po prostu dodanie SYS_ADMINlub w NET_ADMINrazie potrzeby.

ivuk
źródło
Dzięki, exec_linux.gopomogłem. Próbowałem sklonować repozytorium dokera, aby je przejrzeć, ale ponieważ zajęło mi to kilka godzin, po prostu o tym zapomniałem :)
Jakov Sosic
Aby uruchomić Chrome, istnieje o wiele lepsze rozwiązanie wymienione tutaj: github.com/docker/for-linux/issues/496#issuecomment-441149510 Myślę, że bardzo korzystne byłoby zaktualizowanie odpowiedzi, aby ludzie zrobili to, co wyjaśnię w ten sam komentarz. Daj mi znać, jeśli się zgadzasz.
Merc
1

Jedną różnicą jest to, że - uprzywilejowani montuje / dev i / sys jako RW, gdzie jako SYS_ADMIN montuje je jako RO. Oznacza to, że uprzywilejowany kontener ma pełny dostęp do urządzeń w systemie. SYS_ADMIN tego nie daje.

mel1990
źródło