Skip to content

X authentication with cookies and xhost ("No protocol specified" error)

mviereck edited this page Mar 23, 2021 · 27 revisions

X authentication

X servers normally run with enabled cookie authentication (X option -auth).

  • Only clients providing the cookie can access the X server.
  • Exceptions from mandatory cookie authentication can be declared with xhost.
  • If an X client is not allowed to access the X server, it throws error No protocol specified. Unable to init server: Could not connect: Connection refused.

XAUTHORITY

The path to the cookie is stored in environment variable XAUTHORITY.

  • Normally the file is ~/.Xauthority or $XDG_RUNTIME_DIR/Xauthority.
  • The file can contain more than one cookie and for more than one X server.
  • X clients read this variable and authenticate themselves at the X server with the cookie.
  • Stored cookies can be seen with xauth list.

Cookies in a container

Access to the X server can be done sharing the X unix socket in /tmp/.X11-unix, e.g. with --volume /tmp/.X11-unix/X0:/tmp/.X11-unix/X0. The cookie from XAUTHORITY cannot be shared immediately but needs some preparation.

  • Cookies contain a server adress family code. That must be overwritten. A way to go:
  • Choose a new cookie file name, e.g. ~/mycookie.
  • Read the cookie from XAUTHORITY, adjust it, and store the result in ~/mycookie.
    Cookiefile=~/mycookie
    Cookie="$(xauth nlist ${DISPLAY} | sed -e 's/^..../ffff/')" 
    echo $Cookie | xauth -f $Cookiefile nmerge -
    
  • Share the new cookie with the container and set XAUTHORITY accordingly
    docker run --env XAUTHORITY=/mycookie \
               --volume ~/mycookie:/mycookie \
               --volume /tmp/.X11-unix/X0:/tmp/.X11-unix/X0 [...]
    

xhost

Exceptions to cookie authentication can be specified with xhost.

  • xhost weakens the X security setup. Prefer to work with cookies.
  • Check current xhost access rules with plain xhost command.
  • X authentication can be disabled entirely with xhost +. Don't do that. No access protection is left, and X can be abused horribly.
  • X access for single local users can be specified with:
    • xhost +SI:localuser:username (Replace username with desired user name).
    • xhost "+SI:localuser:#uid" (Replace uid with desired user uid).
    • This can be revoced with - instead of +, e.g. xhost -SI:localuser:username.
    • Often seen use case: Allow root access to X: xhost +SI:localuser:root
Clone this wiki locally