Środowisko

• MacOS Sierra 10.12.6
• Wersja Docker 17.09.0-ce, build afdb6d4
• Ubuntu 16.04
• XQuartz 2.7.9

Chcę otworzyć przeglądarkę Chromium z kontenera dokowanego na pulpicie komputera Mac.

docker run -i -t ubuntu:16.04 /bin/bash
apt-get update
apt-get install alsa-base chromium-browser xauth
adduser myuser

Popełnić

docker commit 2862a7bfcc2f  acme/mycontainer:0.1

Uruchamianie przeglądarki chromu myuserz poziomu FAIL kontenera

docker run --user myuser -i -t acme/mycontainer:0.1 /usr/bin/chromium-browser
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

Założę się, że jest coś więcej

Jakieś wskazówki?

UDPATE - za pomocą --privileged

Usuwa błąd Zobacz wątek dotyczący błędu serwera, ale interfejs użytkownika się nie wyświetla

docker run \
       --privileged \
       --user mysuer \
       -i -t acme/mycontainer:0.1 /usr/bin/chromium-browser

i ten

docker run \
   --privileged \
   --net host \
   -v /tmp/.X11-unix:/tmp/.X11-unix \
   -e DISPLAY=$DISPLAY \
   -e XAUTHORITY=/.Xauthority \
   -v ~/.Xauthority:/.Xauthority:ro \
   --name chromium \
   --user mysuser \
   -i -t acme/mycontainer:0.1 /usr/bin/chromium-browser

Chrom nie pojawia się

AKTUALIZACJA 20171011

docker run \
   --privileged \
   --net host \
   -v /tmp/.X11-unix \
   -e DISPLAY \
   --name chromium \
   --user myuser \
   -i -t acme/mycontainer:0.1 \
   bash

Gtk: cannot open display: [...] org.macosforge.xquartz:0Błąd uruchamiania Chromium

$ chromium-browser --verbose
[37:37:1011/154632.348303:VERBOSE1:breakpad_linux.cc(1978)] Breakpad disabled
[1:1:1011/154632.378280:VERBOSE1:zygote_main_linux.cc(537)] ZygoteMain: initializing 0 fork delegates
[1:1:1011/154632.378653:INFO:cpu_info.cc(50)] Available number of cores: 4
[37:37:1011/154632.381303:WARNING:browser_main_loop.cc(275)] Gtk: cannot open display: \
      /private/tmp/com.apple.launchd.Y2wR3QWw57/org.macosforge.xquartz:0

Na moim komputerze Mac edytowane sshd_config

sudo vim /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10
XAuthLocation /opt/X11/bin/xauth

Na moim Macu DISPLAY

$ env | grep DISPLAY
DISPLAY=/private/tmp/com.apple.launchd.Y2wR3QWw57/org.macosforge.xquartz:0

Na dysku

ls -al /private/tmp/com.apple.launchd.gCYQToI4lb/*
srw-rw-rw-  1 joel  wheel     0B Oct 11 17:50 
/private/tmp/com.apple.launchd.gCYQToI4lb/org.macosforge.xquartz:0=

Twoja potrzeba przypomina mi subuser . Zaprojektowano go do uruchamiania aplikacji użytkownika końcowego w kontenerze dokowanym w celu ochrony prywatności i zwiększenia bezpieczeństwa.

Nie mam komputera Mac do eksperymentowania, ale oto kilka ogólnych sugestii:

X11 jest zwykle chroniony za pomocą pliku klucza, który może odczytać tylko użytkownik będący właścicielem wyświetlacza, wykorzystując w ten sposób uprawnienia systemu plików do zapewnienia, że ​​tylko inne programy, które mogą odczytać ten plik, mogą się połączyć. Klienci czytają ten plik, a następnie powtarzają jego zawartość na serwerze przez gniazdo. Więc myślę, że byłeś na dobrej drodze

-e XAUTHORITY=/.Xauthority \
-v ~/.Xauthority:/.Xauthority:ro \

Następnie wyświetlasz ustawienia przekazywania SSH X11, ale nie wskazuje, że ssh do kontenera dokowanego. Przekazywanie SSH jest zwykle używane przez:

ssh $HOST -X program-which-launches-gui

Aby to zrobić, musisz uruchomić serwer SSH wewnątrz kontenera dokowanego, co wymaga trochę wysiłku ...

Następnie pokazujesz, DISPLAY=/path/to/socketktórego wcześniej nie używałem. Jeśli jest to wynalazek MacOS, zadokowane Ubuntu może nie zrozumieć tego formatu.

Na koniec możesz zobaczyć, co chrom próbuje zrobić za pomocą polecenia „strace” z wnętrza kontenera dokowanego.

strace chromium-browser 2>&1 | egrep "open|stat|connect|bind"

Może to pomóc w zawężeniu, które konkretne operacje kończą się niepowodzeniem tuż przed poddaniem się.