-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Suggestion] Apply an overlayfs to /tmp/.X11-unix #451
Comments
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 🤔 but if it's possible it would be really interesting to explore |
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. |
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 containers/podman#13040, but its beyond my knowledge implement this. |
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. |
Threw this together as a test, can confirm gamescope works just fine now and nothing else seems to mind. |
@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. |
Would you be able to toss the overlay command into the default launch command, and have a launch argument to disable it (like |
Thanks a lot @KyleGospo that is extremely useful! Will do some tests, when I have some more time 👍 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 |
@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
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:
Gamescope not working:
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:
For anyone else looking for this, the working command for creating a new box appears to be:
|
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.The text was updated successfully, but these errors were encountered: