[Suggestion] Apply an overlayfs to /tmp/.X11-unix

[orowith2os]

Is your feature request related to a problem? Please describe. Running Gamescope and other X/Xwayland apps that make a new X server inside of distrobox ATM require you to chown /tmp/.X11-unix

Describe the solution you'd like Flatpak works around this by applying an overlayfs, and I believe that Distrobox can do the same.

Describe alternatives you've considered N/A AFAIK, aside from the standard chown, which isn't a good idea imo.

[89luca89]

this could be really interesting, do you have any pointer to what flatpak does?

I don't know if we can overlay the same file over itself with different permissions :thinking: but if it's possible it would be really interesting to explore

[orowith2os]

All I know is that flatpak applies some form of overlay to the X sockets for new servers, I'm not sure on how exactly they mitigate some potential issues. I'll have to look more into that and find where in the source code it applies the overlayfs.

[tjssoldier]

This seems to be a podman problem, docker does not have this issue, i can run gamescope without a problem using docker. Apparently there is a solution for this here https://github.com/containers/podman/discussions/13040, but its beyond my knowledge implement this.

[orowith2os]

Docker doesn't have this issue because it's containers run with root access -- podman runs rootless.

I doubt that a podman distrobox container would have any issues with making a new X servers if it's running as root.

[KyleGospo]

distrobox create --name archtest --image archlinux:latest --init-hooks "install -o 1000 -g 1000 -d /tmp/.X11-unix-$(cat /etc/hostname)-upper;install -o 1000 -g 1000 -d /tmp/.X11-unix-$(cat /etc/hostname)-work;mount -t overlay -o lowerdir=/tmp/.X11-unix,upperdir=/tmp/.X11-unix-$(cat /etc/hostname)-upper,workdir=/tmp/.X11-unix-$(cat /etc/hostname)-work overlay /tmp/.X11-unix"

Threw this together as a test, can confirm gamescope works just fine now and nothing else seems to mind.

[KyleGospo]

@89luca89 Any thoughts on the overlay above? I'd be glad to open a PR if you think something similar to this is a workable solution.

Flatpak is using bwrap to do this same thing.

[orowith2os]

@89luca89 Any thoughts on the overlay above? I'd be glad to open the PR if you think something similar to this is a workable solution.

Flatpak is using bwrap to do this same thing.

Would you be able to toss the overlay command into the default launch command, and have a launch argument to disable it (like --xserver-host-integration?

[89luca89]

Thanks a lot @KyleGospo that is extremely useful! Will do some tests, when I have some more time :+1:

You can start adding a PR for it in the meantime, explaining if this creates some problems on the integration, and needs a flag to disable it like @orowith2os is suggesting If no integration problem is created, we could even skip the flag

[orowith2os]

@KyleGospo Here's another suggestion as to how you could handle that, since just applying an entire overlayfs is bound to have issues:

Make an entirely new /tmp/.X11-unix, and bindmount the host's main X server into it. Then, it won't have conflicts from the host, and integrates just fine, while allowing new X servers to be created. I believe that is how Flatpak actually does that?

(this is assuming I understand that command properly)

[KenJyn76]

@KyleGospo Here's another suggestion as to how you could handle that, since just applying an entire overlayfs is bound to have issues:

Make an entirely new /tmp/.X11-unix, and bindmount the host's main X server into it. Then, it won't have conflicts from the host, and integrates just fine, while allowing new X servers to be created. I believe that is how Flatpak actually does that?

(this is assuming I understand that command properly)

Using

distrobox create --name archtest --image archlinux:latest --init-hooks "install -o 1000 -g 1000 -d /tmp/.X11-unix-new; mount --bind /tmp/.X11-unix-new /tmp/.X11-unix"

creates a container that indeed can run X11 windows, like gamescope. The windows don't actually appear, though. Potentially because the window is actually on a different X11 server than the hose is running? I'm not sure. Gamescope, at least, does not throw an error about not being able to access /tmp/.X11-unix, but the window does not appear.

Gamescope working:

[liam@games ~]$ gamescope glxgears
No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
wlserver: [backend/headless/backend.c:68] Creating headless backend
vulkan: selecting physical device 'AMD Radeon RX 5700 XT (RADV NAVI10)': queue family 1
vulkan: physical device supports DRM format modifiers
vulkan: supported DRM formats for sampling usage:
vulkan:   0x34325241
vulkan:   0x34325258
vulkan:   0x3231564E
wlserver: Running compositor on wayland display 'gamescope-0'
wlserver: [backend/headless/backend.c:16] Starting headless backend
wlserver: [xwayland/server.c:108] Starting Xwayland on :2
wlserver: [types/wlr_compositor.c:673] New wlr_surface 0x563bc7c2b3d0 (res 0x563bc7c320c0)
wlserver: [xwayland/server.c:273] Xserver is ready
pipewire: stream state changed: connecting
pipewire: stream state changed: paused
pipewire: stream available on node ID: 76
pipewire: renegotiating stream params (size: 1280x720)
wlserver: [types/wlr_compositor.c:673] New wlr_surface 0x563bc7c448d0 (res 0x563bc7c37fe0)

Gamescope not working:

[liam@archtest ~]$ gamescope glxgears
No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
wlserver: [backend/headless/backend.c:68] Creating headless backend
vulkan: selecting physical device 'AMD Radeon RX 5700 XT (RADV NAVI10)': queue family 1
vulkan: physical device supports DRM format modifiers
vulkan: supported DRM formats for sampling usage:
vulkan:   0x34325241
vulkan:   0x34325258
vulkan:   0x3231564E
wlserver: Running compositor on wayland display 'gamescope-0'
wlserver: [backend/headless/backend.c:16] Starting headless backend
wlserver: [xwayland/server.c:108] Starting Xwayland on :2
wlserver: [types/wlr_compositor.c:673] New wlr_surface 0x55983e3f3f60 (res 0x55983e4624e0)
wlserver: [xwayland/server.c:273] Xserver is ready
pipewire: stream state changed: connecting
pipewire: stream state changed: paused
pipewire: stream available on node ID: 76
xwm: execvp failed: No such file or directory
pipewire: renegotiating stream params (size: 1280x720)

EDIT: It looks like it does work, actually! It was something else missing in the distrobox (not sure what) that caused the window to not appear. Cloning my working pod with the new init hook does work perfectly:

distrobox create --name archtest --clone games --init-hooks "install -o 1000 -g 1000 -d /tmp/.X11-unix-new; mount --bind /tmp/.X11-unix-new /tmp/.X11-unix"

For anyone else looking for this, the working command for creating a new box appears to be:

distrobox create -n archtest -i archlinux:latest --init-hooks "install -o 1000 -g 1000 -d /tmp/.X11-unix-new; mount --bind /tmp/.X11-unix-new /tmp/.X11-unix"