fix: x server access

[perrin4869]

the latest changes added an additional check to the call to xhost, this prevented the container from being able to access xserver on my host. also, the screensaver inhibit code was lost in https://github.com/netbrain/zwift/pull/108, I returned it here

[sHedC]

@perrin4869 - I did change it to use XAUTHORITY, can you tell me what XAUTHORITY is on your host, also what OS/ Display manager (Gnome/ X11 etc) .

@netbrain - don't see any issue with this push request it seems that X is different on different systems so might need that setting.

[perrin4869]

@sHedC I'm running i3wm on slackware64-current, ~/.Xauthority exists but I am not familiar with X server permissions settings enough to know why this change is required on my system 😅

[sHedC]

Me either :). Basically the XAUTHORITY Environment variable is used to identify access to the Xhost. However it seems different distributions/ WM's change it.

I think that it seems safer to run the xhost regardless I see you can also run it in wayland so relaxing that it runs as long as you are not trying experimental wayland.

I love slackware used to build it if I remember with about 15 floppy disks in the 90's. Not used it since 2000.

[perrin4869]

haha, yeah, I hear that a lot from more senior devs 😅 my intro to linux was circa 2006 with Ubuntu, but been using slack as my main machine since 2013 or so to get more familiar with linux, and I never left ^^;; I'm interested in digging deeper into this, I'll post back if I find something

[perrin4869]

ok, so I looked a bit into this topic, and I think the issue is that the cookie listed by xauth depends on the hostname. In my case, I have:

$ xauth list                                                                                                                                                       
landau.julian.dotcore.co.il/unix:0  MIT-MAGIC-COOKIE-1  57652db05ffc7b47d182bfd8b2987260
$ hostname                                                                                                                                                         
landau.julian.dotcore.co.il

I think that when the container tries to connect using this cookie, it gets rejected due to the different hostname. According to the internet, it is possible to create a cookie in such a way that the hostname does not matter

XAUTH=~/.xauth.docker
touch $XAUTH
xauth nlist :0 | sed -e 's/^..../ffff/' | xauth -f $XAUTH nmerge -

And then use ~/.xauth.docker instead of ~/.Xauthority (or whatever file $XAUTHORITY is pointing to in your system) and should be good to go? but haven't properly tested this. The nice thing about this approach, if it works, is that it doesn't depend on the container hostname, and can be setup before the container is run.

[netbrain]

Why not just set the container hostname to be equal to host machine?

[sHedC]

Seems this is only an option for docker there is no option for this in podman.

[netbrain]

Really? https://docs.podman.io/en/latest/markdown/podman-run.1.html#hostname-h-name

Docs says it's possible.

[perrin4869]

actually, never mind, the hostname wasn't the problem at all ^^;; turns out that XAUTHORITY was only being set for wayland...

[sHedC]

Stopped worrying :)

I think XAUTHORITY is supposed be the way forward however would prefer to have a method that works for the majority of people and not break it as its the least important thing to the program actually working :)

I will probably install Slack and try it, need to work oout if I can automate this with Proxmox as this is now my daily driver if I can automate will make it a lot easier.

[perrin4869]

Since slack or gentoo ship rather unmodified builds, if you pair that with a simple desktop manager such as i3wm, it's a good platform to test software like this, since you are almost guaranteed not to be fighting with the WM for control over the X server, power settings, dbus, etc :)