Linux GUI Applications in Containers

Last update: 2023-02-11 21:21:45 +0800 +0800
Available translations: 日本語 / 中文(简体) / 中文(繁體)

Containers do not automatically have access to the host display session. A GUI client needs the appropriate display socket, environment variables, and credentials; exposing them grants the container meaningful control over the user session and should be done only for trusted images.

X11 #

For X11, mount the host socket directory—typically /tmp/.X11-unix—and pass DISPLAY. The client also needs the matching Xauthority cookie, usually supplied by mounting a narrowly scoped cookie file and setting XAUTHORITY. Do not use xhost +; it disables access control for the display. X11Docker can create a more constrained wrapper around this setup.

Wayland #

Wayland clients connect to $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY, commonly /run/user/<uid>/wayland-0. A container must run as a compatible user and receive only the necessary runtime socket and environment. Many desktop sessions provide Xwayland, so an X11 client can also use the X11 route. Native Wayland support avoids that compatibility layer but does not make the socket safe to share with untrusted code.

Remote Desktops #

VNC is often a better boundary for remote or streamed applications: a server owns a separate desktop and clients see encoded pixels rather than the host’s privileged display socket. It is also useful where browser delivery, recording, or session isolation is required.

Comments

Read or comment on GitHub (sign-in required to comment)