Meio Ambiente

• MacOS Sierra 10.12.6
• Docker versão 17.09.0-ce, compilação afdb6d4
• Ubuntu 16.04
• XQuartz 2.7.9

Quero abrir o navegador Chromium de um contêiner de docker na área de trabalho do Mac.

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

Confirmar

docker commit 2862a7bfcc2f  acme/mycontainer:0.1

Executando o navegador Chromium a partir myuserdo container FAIL

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

Aposto que há um pouco mais

Alguma dica?

UDPATE - usando --privileged

Remove o erro Veja o tópico na falha do servidor, mas a interface do usuário não aparece

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

e este

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

O cromo não aparece

ATUALIZAÇÃO 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:0Erro ao iniciar o 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

No meu Mac editado sshd_config

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

No meu Mac DISPLAY

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

No disco

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=

Sua necessidade me lembra subusuário . Ele foi projetado para executar o aplicativo do usuário final em um contêiner de encaixe para proteger a privacidade e aumentar a segurança.

Não tenho um Mac para experimentar, mas aqui estão algumas sugestões gerais:

O X11 geralmente é protegido com um arquivo de chave que só pode ser lido pelo usuário que possui o monitor, usando assim as permissões do sistema de arquivos para afirmar que apenas outros programas que podem ler esse arquivo podem se conectar. Os clientes leem esse arquivo e repetem seu conteúdo no servidor através do soquete. Então, acho que você estava no caminho certo com

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

Em seguida, você mostra as configurações de encaminhamento do SSH X11, mas nenhuma indicação de que você ssh no contêiner do docker. O encaminhamento SSH é normalmente usado por:

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

Para fazer isso, você precisa executar um servidor SSH dentro do contêiner do docker, o que é um pouco de esforço ...

Em seguida, você mostra um DISPLAY=/path/to/socketque eu não usei antes. Se for uma invenção do MacOS, o Ubuntu dockerizado pode não entender esse formato.

Finalmente, você pode ver o que o chrome está realmente tentando fazer usando o comando 'strace' de dentro do contêiner do docker.

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

Isso pode ajudá-lo a restringir quais operações específicas falham antes de desistir.