> You'll often see xhost + suggested as the "just make it work" answer, and it does — by turning host-based access control off entirely. Every client from every host can then connect to your display without any cookie at all.
> On a single-user machine that sounds harmless, but X has no isolation between clients: anyone who can reach the server can read your keystrokes, grab the contents of any window, and inject synthetic input. xhost + hands that capability to every local user and, if your server listens on TCP, to the network. Even the narrower xhost +local: still trusts every UID on the box.
Does modern Xorg even support TCP? I know it doesn't default to allowing it, and the last time I actually wanted to run X11 over the network I ended up using socat against the socket file. Controlling access by user could have some value, but only under very specific threat models, especially since containers won't be able to reach the socket unless you give it to them on purpose. (Actually, can you just chmod o-rwx the socket?)
So I'm really skeptical of ever practically needing a more complicated fix when you can just xhost +
Notably, "si" or "server interpreted" is not cryptographically secure. However, you can share MIT-MAGIC-COOKIE values easily by copy-paste into another user's xauth command.
> xhost + hands that capability to every local user and, if your server listens on TCP, to the network. Even the narrower xhost +local: still trusts every UID on the box.
I'm not defending xhost or advocating to use it but... If you mention narrower version of xhost, then why stop at:
xhost +local:
and not mention that you can do:
xhost +si:localuser:jack
As an intriguing unrelated sidenote you can do:
xhost +si:localuser:jack
open an app, then do:
xhost -si:localuser:jack
and then user jack cannot, except through the app already launched, display on the X server.
Memories from '96: We had these Sun computers at the university we called "cpu servers". At home we ran Linux (or sometimes Windows 3/95 with Exceed) on like a 486. In between a 10 Mbit/s Ethernet network. Everything had public IPs. Cleartext telnet was still ok.
We ran those weird X11-based apps on these "cpu servers" required for courses that way. Web browsing was faster locally.
> You'll often see xhost + suggested as the "just make it work" answer, and it does — by turning host-based access control off entirely. Every client from every host can then connect to your display without any cookie at all.
> On a single-user machine that sounds harmless, but X has no isolation between clients: anyone who can reach the server can read your keystrokes, grab the contents of any window, and inject synthetic input. xhost + hands that capability to every local user and, if your server listens on TCP, to the network. Even the narrower xhost +local: still trusts every UID on the box.
Does modern Xorg even support TCP? I know it doesn't default to allowing it, and the last time I actually wanted to run X11 over the network I ended up using socat against the socket file. Controlling access by user could have some value, but only under very specific threat models, especially since containers won't be able to reach the socket unless you give it to them on purpose. (Actually, can you just chmod o-rwx the socket?)
So I'm really skeptical of ever practically needing a more complicated fix when you can just xhost +
It is likely that your desktop Linux distro, or whatever, is configured out-of-box to run the X server that only listens on the unix:0 domain.
You can reconfigure it, restart it, or start a secondary server. And check your firewall/packet filtering setup while you're at it.
There are several cryptographic security methods for the xauth(1) system.
https://manpages.ubuntu.com/manpages/resolute/man7/Xsecurity...
Notably, "si" or "server interpreted" is not cryptographically secure. However, you can share MIT-MAGIC-COOKIE values easily by copy-paste into another user's xauth command.
> xhost + hands that capability to every local user and, if your server listens on TCP, to the network. Even the narrower xhost +local: still trusts every UID on the box.
I'm not defending xhost or advocating to use it but... If you mention narrower version of xhost, then why stop at:
and not mention that you can do: As an intriguing unrelated sidenote you can do: open an app, then do: and then user jack cannot, except through the app already launched, display on the X server.Memories from '96: We had these Sun computers at the university we called "cpu servers". At home we ran Linux (or sometimes Windows 3/95 with Exceed) on like a 486. In between a 10 Mbit/s Ethernet network. Everything had public IPs. Cleartext telnet was still ok.
We ran those weird X11-based apps on these "cpu servers" required for courses that way. Web browsing was faster locally.
I mostly get away with xrdp, it works perfectly.