Sharing X11 Server Across Hosts Using FamilyWild for Authorization

The X11 Authorization Problem

When attempting to run an X11 application from within a container, a chroot, or over SSH with a bind-mounted .Xauthority file, users often encounter an "Authorization required, but no authorization protocol specified" error. This occurs even when the .Xauthority file is present and seemingly valid.

The core issue is that an .Xauthority file contains cookies keyed by a family and a hostname. An X client searches for an entry whose hostname matches the machine it believes it is running on. If the client's hostname differs from where the cookie was originally minted (e.g., inside a container or over an un-forwarded socket), the cookie is rejected, leading to authorization failure.

FamilyWild as a Solution

X11 provides a wildcard family, known as FamilyWild, with a numeric value of 0xffff. A cookie configured with this family will match any hostname, effectively bypassing the hostname-specific authorization problem. Instead of trying to force the client's hostname to match the cookie, the cookie itself is modified to be universally applicable.

The modification involves rewriting the first field of the numeric output of `xauth nlist` from the original family (e.g., 0100 for FamilyLocal) to `ffff` for FamilyWild. This rewritten entry is then merged into a new, portable .Xauthority file.

Implementing the Fix

The fix is a single line using `sed` to modify the output of `xauth nlist`. The command `xauth nlist :0 | sed 's/^..../ffff/' | xauth -f /tmp/portable.Xauthority nmerge -` creates a new .Xauthority file (`/tmp/portable.Xauthority`) where the cookie's family is set to FamilyWild. This new file can then be used by X11 applications in environments where hostname mismatches would otherwise cause authorization errors.

The change is minimal, affecting only the first two bytes of the binary record that define the family, changing it from the specific FamilyLocal (0100) to the wildcard FamilyWild (ffff).