How can I run an X11 application in an isolated Podman container on RHEL 10?
Asked by
MellowCedar42
I'm running RHEL 10.2 with GNOME 49 and need to launch an X11 application from inside a Podman container that uses its own IP address and an internal custom network. The container is created with `podman network create --internal pod_dev` and receives the X11-related environment variables, socket mounts, and configuration files I know about, but the application still cannot connect to the display. The same setup works on Fedora 44 and Ubuntu. Using `--network=host` makes the application work, but I need the container to remain on its own network interface and address. I've tried many combinations of environment variables, volume mounts, and runtime flags without success. What should I check or configure differently on RHEL?
Answers
Check the X11 authentication cookie first. With a custom network, the container has a different hostname, so an `.Xauthority` entry created for the host may not match the container's hostname. Inside the container, compare `xauth list` with the output of `hostname`. As a quick test, run the container with `--hostname $(hostname)`. If that works, you can instead create a wildcard cookie, mount it into the container, and set `XAUTHORITY` to that file. For example: `xauth nlist $DISPLAY | sed -e 's/^....../fffffff/' | xauth -f /tmp/.podman.xauth nmerge -`. Make sure the X socket is mounted as well.
Reply to this answer
The basic pieces are mounting the host's X11 Unix socket into the container and providing a matching Xauthority cookie. Passing `DISPLAY` alone is not enough. Check that the socket path in `DISPLAY` exists inside the container, that the mounted authority file is readable by the application user, and that the cookie matches the container's hostname or uses a wildcard entry. If all of that looks correct, inspect SELinux audit logs and temporarily test with the appropriate labeling or a controlled SELinux diagnostic to determine whether policy is denying access.
Reply to this answer
It may help to isolate the problem by testing X forwarding outside the container first. Confirm that forwarding works against a simple local target such as `127.0.0.1`, then test the container address. If using SSH for the test, verify the display environment and try both trusted and untrusted forwarding options where appropriate. Once basic forwarding works, check the connection between SSH and the X server separately. On RHEL, also verify SELinux permissions and firewall rules, since either can block access even when the socket and environment variables are correct.
MellowCedar42: I'm not sure how SSH would reach a container on an internal network. I may use it only as a diagnostic test, but the container needs to keep its isolated network configuration.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowCedar42: I tried a different approach before and it didn't work, but I'll test the hostname and wildcard-cookie method. Thanks for taking the time to explain it.