11 ms·

You can also do it with this one-liner: docker run -it --rm -e DISPLAY --net=host -v $XAUTHORITY:/root/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix debian:11-s

by mg 5y ago

You can also do it with this one-liner: docker run -it --rm -e DISPLAY --net=host -v $XAUTHORITY:/root/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix debian:11-slim Then inside the container, run: apt update apt install firefox-esr firefox Now Firefox runs inside the container but displays on your hosts screen and you can use it right away.

bheadmaster 5y ago
Thanks, this is much simpler than the original post. Here's the equivalent Dockerfile + docker-compose.yaml for convenience: # Dockerfile FROM debian:11-slim RUN apt-get -y update && apt-get -y install firefox-esr CMD ["firefox"] # docker-compose.yaml services: firefox: image: firefox build: . environment: DISPLAY: ${DISPLAY} network_mode: host volumes: - ${XAUTHORITY}:/root/.Xauthority - /tmp/.X11-unix:/tmp.X11-unix This way you can run it with just: docker-compose up
- moody5bundle 5y ago
  if you want to remove network_mode=host you need to run firefox with the --no-xshm flag
ThePhysicist 5y ago
Yes, I think few people seem to realize X Windows can be operated over a network as well. I used to do that with the Windows Subsystem for Linux to use the KDE Konsole and other great tools on my Windows machine using an X server running on the Windows side and a few environment variable tweaks on the Linux side. My colleagues were always confused when they saw the Linux UI seamlessly mixed with the Windows stuff on my display. For the use case mentioned in the article xvfb probably makes more sense though as that stuff often runs on a server and you don't want to stream the output somewhere to work with it interactively.
- zozbot234 5y ago
  This is not running X on any network, just sharing access to the resources that the containerized app needs to find the X server on the same host. There's probably an equivalent incantation for Wayland, too.
  - nrdvana 5y ago
    Well, that's sort of splitting hairs... It is a unix socket, which at the API level is the same as a network connection, but the kernel skips the hassle of attaching protocol headers and routing the packets. The example above is writing and reading every X11 message over a socket, and not reaching into /dev on the host, else it would need additional parameters added to the docker command. I'm not current on Wayland, but as of a few years ago all attempts to run it non-locally required the X11 back-compat layer. I have no idea what /dev nodes would be required to be shared for wayland to run in a chroot.
    - OJFord 5y ago
      I found your comment grepping for someone sharing how to do it in Wayland, so here it is for the next person: docker run -e XDG_RUNTIME_DIR=/tmp \ -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \ -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \ --user=$(id -u):$(id -g) \ imagename waylandapplication Pretty simple and reasonable really, just needs to use the same Wayland socket and (in order to access it) user ID. From: https://unix.stackexchange.com/a/359244 https://unix.stackexchange.com/a/359244 I suppose if you were adventurous you could give it whatever other known user ID, and start a separate Wayland compositor for it. But I don't know why you would, when surely the point is to get containerised GUIs visible to you alongside others. Containerised multi-seat I suppose?
      - bdavis__ 5y ago
        thanks for posting this, but I don't think it meets the definition of "Pretty simple".
bstpierre 5y ago
Also this method avoids “xhost +” which is a huge security hole
remram 5y ago
This has less isolation. The container has full access to your X server and can record your screen or log all key presses, for example. It also has access to the host's network interfaces, and can access services bound to localhost (even if firewalled). There is little point in running software this way, if the software is available on the host. On the other hand the use cases that the article describes can already be accomplished by Firefox's "account containers" feature or just creating another profile and running `firefox --no-remote`
- joombaga 5y ago
  The container would only be able to record the screens or key presses that occur in the same xserver, right? I never thought about access to localhost services. I'm guessing there's some xserver configuration that could prevent that.
  - 0x0 5y ago
    Nobody runs more than one X server. And the X server isn't involved with other localhost services.
    - joombaga 5y ago
      I don't intend to run more than one X server. Most of my GUI applications don't use X.
    - d110af5ccf 5y ago
      Wait I thought distros ran one X server per logged in user account and put them on different ttys. Out of the box on Ubuntu I can log in as two separate users simultaneously and switch between those unlocked sessions as well as the login screen by changing the tty. If you pass the GPU device node through to an LXC container I believe you can run an X or Wayland server fully inside of it but I'm not sure if changing ttys will work correctly because you might need access to more than just the GPU to handle the handoff with the kernel correctly.
  - remram 5y ago

by mg 5y ago

bheadmaster 5y ago

Thanks, this is much simpler than the original post. Here's the equivalent Dockerfile + docker-compose.yaml for convenience: # Dockerfile FROM debian:11-slim RUN apt-get -y update && apt-get -y install firefox-esr CMD ["firefox"] # docker-compose.yaml services: firefox: image: firefox build: . environment: DISPLAY: ${DISPLAY} network_mode: host volumes: - ${XAUTHORITY}:/root/.Xauthority - /tmp/.X11-unix:/tmp.X11-unix This way you can run it with just: docker-compose up

moody5bundle 5y ago
if you want to remove network_mode=host you need to run firefox with the --no-xshm flag

ThePhysicist 5y ago

Yes, I think few people seem to realize X Windows can be operated over a network as well. I used to do that with the Windows Subsystem for Linux to use the KDE Konsole and other great tools on my Windows machine using an X server running on the Windows side and a few environment variable tweaks on the Linux side. My colleagues were always confused when they saw the Linux UI seamlessly mixed with the Windows stuff on my display. For the use case mentioned in the article xvfb probably makes more sense though as that stuff often runs on a server and you don't want to stream the output somewhere to work with it interactively.

zozbot234 5y ago
This is not running X on any network, just sharing access to the resources that the containerized app needs to find the X server on the same host. There's probably an equivalent incantation for Wayland, too.
- nrdvana 5y ago
  Well, that's sort of splitting hairs... It is a unix socket, which at the API level is the same as a network connection, but the kernel skips the hassle of attaching protocol headers and routing the packets. The example above is writing and reading every X11 message over a socket, and not reaching into /dev on the host, else it would need additional parameters added to the docker command. I'm not current on Wayland, but as of a few years ago all attempts to run it non-locally required the X11 back-compat layer. I have no idea what /dev nodes would be required to be shared for wayland to run in a chroot.
  - OJFord 5y ago
    I found your comment grepping for someone sharing how to do it in Wayland, so here it is for the next person: docker run -e XDG_RUNTIME_DIR=/tmp \ -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \ -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \ --user=$(id -u):$(id -g) \ imagename waylandapplication Pretty simple and reasonable really, just needs to use the same Wayland socket and (in order to access it) user ID. From: https://unix.stackexchange.com/a/359244 https://unix.stackexchange.com/a/359244 I suppose if you were adventurous you could give it whatever other known user ID, and start a separate Wayland compositor for it. But I don't know why you would, when surely the point is to get containerised GUIs visible to you alongside others. Containerised multi-seat I suppose?
    - bdavis__ 5y ago
      thanks for posting this, but I don't think it meets the definition of "Pretty simple".

bstpierre 5y ago

Also this method avoids “xhost +” which is a huge security hole

remram 5y ago

This has less isolation. The container has full access to your X server and can record your screen or log all key presses, for example. It also has access to the host's network interfaces, and can access services bound to localhost (even if firewalled). There is little point in running software this way, if the software is available on the host. On the other hand the use cases that the article describes can already be accomplished by Firefox's "account containers" feature or just creating another profile and running `firefox --no-remote`

joombaga 5y ago
The container would only be able to record the screens or key presses that occur in the same xserver, right? I never thought about access to localhost services. I'm guessing there's some xserver configuration that could prevent that.
- 0x0 5y ago
  Nobody runs more than one X server. And the X server isn't involved with other localhost services.
  - joombaga 5y ago
    I don't intend to run more than one X server. Most of my GUI applications don't use X.
  - d110af5ccf 5y ago
    Wait I thought distros ran one X server per logged in user account and put them on different ttys. Out of the box on Ubuntu I can log in as two separate users simultaneously and switch between those unlocked sessions as well as the login screen by changing the tty. If you pass the GPU device node through to an LXC container I believe you can run an X or Wayland server fully inside of it but I'm not sure if changing ttys will work correctly because you might need access to more than just the GPU to handle the handoff with the kernel correctly.
- remram 5y ago