X11 Authorization Fails in Containers? Fix It with a One-Line sed
Sharing an X11 Server Across Hosts with FamilyWild
When running X11 apps in containers, chroots, or over SSH with a bind-mounted .Xauthority, you may hit 'Authorization required, but no authorization protocol specified'. The cause: the cookie's hostname doesn't match the client's. The fix: rewrite the cookie's family to FamilyWild (0xffff) using xauth nlist and sed. This makes the cookie match any hostname. Unlike xhost +, which disables access control entirely, FamilyWild keeps the secret required, so it's safer. Just keep the cookie file at 0600 and share it only with trusted environments.
The cookie is present and valid, but its hostname doesn't match, so the client never offers it and X falls back to "no authorization protocol."
- somat
Running X open as a sort of shared network attached monitor is pretty fun, granted it is only really useful as a sort of large control room style display as all window operation have to run via cli tools.
But it is neat for anyone to just be able to throw a application up on the big master display.
- yjftsjthsd-h
> 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 +
- lysace
Memories from '96: We had these beefy/expensive Sun computers at the university we called "cpu servers". At home we ran Linux with XFree86 (or sometimes Windows 95/NT with Exceed) on like a 486. In between a 10 Mbit/s Ethernet network. Everything had public IPs. Cleartext telnet was still the norm.
We ran some weird X11-based apps on these Sun machines required for courses that way. Web browsing was faster locally, even with a lowly 486.