Medio ambiente

• MacOS Sierra 10.12.6
• Docker versión 17.09.0-ce, compilación afdb6d4
• Ubuntu 16.04
• XQuartz 2.7.9

Quiero abrir el navegador Chromium desde un contenedor acoplable en mi escritorio Mac.

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

Cometer

docker commit 2862a7bfcc2f  acme/mycontainer:0.1

Ejecutando el navegador myuserChrome desde el contenedor 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

Apuesto a que hay un poco más

Cualquier puntero?

UDPATE - usando --privileged

Elimina el error See thread on serverfault pero la IU no aparece

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

y éste

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

El cromo no aparece

ACTUALIZACIÓN 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:0Error de inicio de cromo

$ 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

En mi Mac editado sshd_config

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

En mi mac DISPLAY

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

En el 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=

Su necesidad me recuerda subusuario . Ha sido diseñado para ejecutar aplicaciones de usuario final en un contenedor acoplable para proteger la privacidad y aumentar la seguridad.

No tengo una Mac para experimentar, pero aquí hay algunas sugerencias generales:

X11 generalmente está protegido con un archivo de clave que solo puede ser leído por el usuario propietario de la pantalla, por lo que utiliza los permisos del sistema de archivos para afirmar que solo otros programas que pueden leer ese archivo pueden conectarse. Los clientes leen ese archivo y luego repiten su contenido al servidor a través del socket. Entonces, creo que estabas en el camino correcto con

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

A continuación, muestra la configuración de reenvío de SSH X11 pero no indica que haya ingresado en el contenedor acoplable. El reenvío SSH normalmente lo utilizan:

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

Para hacer esto, necesitaría ejecutar un servidor SSH dentro del contenedor acoplable, lo cual es un poco de esfuerzo ...

A continuación, muestra uno DISPLAY=/path/to/socketque no he usado antes. Si se trata de una invención de MacOS, entonces el Ubuntu dockerizado podría no entender ese formato.

Finalmente, puede ver lo que Chrome está intentando hacer realmente usando el comando 'strace' desde el interior del contenedor acoplable.

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

Eso podría ayudarlo a reducir qué operaciones específicas fallan justo antes de que se rinda.