Environnement

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

Je souhaite ouvrir le navigateur Chromium depuis un conteneur Docker sur mon bureau Mac.

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

Commettre

docker commit 2862a7bfcc2f  acme/mycontainer:0.1

Exécution du navigateur Chrome à myuserpartir du conteneur 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

Je parie qu'il y a un peu plus

Des pointeurs?

UDPATE - utilisation --privileged

Supprime l'erreur See thread on serverfault mais l'interface utilisateur ne s'affiche pas

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

et celui-là

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

Le chrome n'apparaît pas

MISE À JOUR 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:0Erreur de démarrage de Chrome

$ 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

Sur mon Mac modifié sshd_config

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

Sur mon Mac DISPLAY

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

Sur disque

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=

Votre besoin me rappelle un sous- utilisateur . Il a été conçu pour exécuter l'application utilisateur final dans un conteneur Docker afin de protéger la confidentialité et d'augmenter la sécurité.

Je n'ai pas de Mac pour expérimenter, mais voici quelques suggestions générales:

X11 est généralement protégé par un fichier clé qui ne peut être lu que par l'utilisateur propriétaire de l'affichage, utilisant ainsi les autorisations du système de fichiers pour affirmer que seuls les autres programmes capables de lire ce fichier peuvent se connecter. Les clients lisent ce fichier, puis répètent son contenu sur le serveur via le socket. Donc, je pense que vous étiez sur la bonne voie avec

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

Ensuite, vous montrez les paramètres de transfert SSH X11 mais aucune indication que vous ssh dans le conteneur Docker. Le transfert SSH est normalement utilisé par:

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

Pour ce faire, vous devez exécuter un serveur SSH à l'intérieur du conteneur Docker, ce qui représente un peu d'effort ...

Ensuite, vous montrez un DISPLAY=/path/to/socketque je n'ai pas utilisé auparavant. S'il s'agit d'une invention MacOS, l'Ubuntu docké peut ne pas comprendre ce format.

Enfin, vous pouvez voir ce que Chrome tente réellement de faire en utilisant la commande «strace» depuis l'intérieur du conteneur Docker.

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

Cela pourrait vous aider à réduire les opérations spécifiques qui échouent juste avant qu'elles n'abandonnent.