I tried it and get avogadro to run without using xhost.
Adapting from the link I give above, this is my dockerfile.
# Install dependencies
RUN apt-get -y update
RUN apt-get -y install xauth firefox avogadro
#Expose a port number
RUN xauth add localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 c9dd5d2e4182e151a3be39db02679bb9
The xauth displayname protocolname hexkey is from host I get from xauth list on the host.
I run the container with
I would like to know if there are security implication here?
Does exposing my container port 8887 bad?
While it work, xauth complain about xauth: file /root/.Xauthority does not exist, is it a problem?
It’s the first time I’ve seen embedding the xauth cookie in the image, that’s a unnecessary burden. You should mount the local xauth cookie in the docker run line. Because by default the cookie matches a hostname, either you’ll have to extract and build a temporary xauth cookie file on the host with FamilyWild, or more simple make the container hostname match the host.
Since you’re running docker, you should run with an unprivileged user, using root inside a container running on a rootful engine is a bad practice, because it equates to root outside the container although with fewer privileges.
Regarding exposing a port from the container, that’s what usually one has to do to access a service inside the container. I can’t tell in this specific case. But since you’re running with net=host the container is already on the host network, so that doesn’t make any sense.
Good you figured it out. For reference, I mentioned the project https://github.com/mviereck/x11docker. Knowing how to achieve this with bare docker commands is nice, but this project makes it much easier for many other cases, like sharing other system resources.
That’s a race between the container entrypoint and the docker exec. The first process startup takes so long that the xauth command is able to complete before the main process / X libs reads the x11 cookie. It might work most of the time, but the usual way to do it is to mount the cookie file instead, so no docker exec is needed. OTOH the approach you used would be helpful to re-use the container across reboots.
It’s like you’ve done earlier, but because you used a hardcoded path instead of $XAUTHORITY, it failed. Then it depends on how your display manager is generating the cookie. On TW sddm is generating an entry with FamilyWild:
$ xauth list
myhostname/unix:0 MIT-MAGIC-COOKIE-1 03265ea28d9868b2e9d8d4948dd3a3aa
#ffff##:0 MIT-MAGIC-COOKIE-1 03265ea28d9868b2e9d8d4948dd3a3aa
Because of the “#ffff#” entry, it should just work inside the container.
If the local .Xauthority doesn’t contain a FW entry, then you’ll either need to set the container hostname to match the host, or generate a new cookie file with FW. x11docker takes care of all this.
I tried x11docker.
I works well without much work, also come with gui, very nice.
The strange thing I found is, I need to install openbox in the docker image and my host machine for the app to have proper size and window border. Is this because x11docker isolate the app from accessing my host wm?