Article URL: https://dobrowolski.dev/article/sharing-an-x-server-across-hosts-with-familywild/ Comments URL: https://news.ycombinator.com/item?id=49147978 Points: 14 # Comments: 3

Ever tried running an X11 application from inside a container, a chroot, or over ssh with a bind-mounted .Xauthority — only to be greeted by the ever-helpful Authorization required, but no authorization protocol specified? The file is right there, mounted read-only where the client expects it, and yet X refuses the connection. The reason is subtle, and the fix is a single line of sed. An .Xauthority file is a list of cookies, and every entry is keyed by a family and a hostname. When a client connects, it doesn't just grab the first cookie it finds — it looks for the entry whose hostname matches the machine the client believes it's running on. That's exactly what breaks the moment the client runs somewhere other than where the cookie was minted. Inside a container the hostname is different; over an un-forwarded socket the client resolves a different name entirely. 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." X has a wildcard family, FamilyWild, whose numeric value is 0xffff. A cookie in this family matches any hostname. So instead of trying to make the client's hostname match the cookie, we rewrite the cookie to match every host. xauth nlist prints entries in a numeric format where the first field is the 4-hex-digit family. Overwrite it with ffff and merge the result into a fresh file: It's worth seeing just how small the edit is. An .Xauthority entry is a packed binary record: a 2-byte family, then length-prefixed address, display number, auth name, and the cookie itself. Dump the original file and the family sits in the very first two bytes — 0100, i.e. FamilyLocal: Now dump the FamilyWild version we just built. Everything is byte-for-byte identical — same myhost address, same cookie — except those first two bytes, now flipped to ffff: