$XAUTHORITY should move into $XDG_RUNTIME_DIR

Bug #1648107 reported by Markus Kuhn
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
lightdm (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Historically, the X authority file was placed into $HOME/.Xauthority such that X11 clients on remote servers could access it in environments in which $HOME is located on a network file system.

Today, this practice has become an anachronism that causes far more problems than it solves:

a) Remote X11 clients are typically started today via "ssh -X", which emulates its own X11 server port $DISPLAY and therefore always creates its own X authority file entry on the remote server. Therefore, there is no longer any practical benefit from having the X authority file located in $HOME.

b) If $HOME is on a network file system that implements "root squash", then commands such as "sudo xterm" or "sudo wireshark" won't work to start an X client with root privileges, as root is not able to read ~/.Xauthority via NFS. :-(

c) If $HOME is on a network file system with Kerberos authentication, then users can easily get locked out by their screensavers once the Kerberos ticket expires. This is because some screen lockers (e.g., gnome-screensaver) invoke a separate utility (e.g., /usr/lib/gnome-screensaver/gnome-screensaver-dialog) in order to ask the user of a locked screen for their password. Such a tool needs to access $XAUTHORITY right before it can display the password prompt, which will fail if the user's Kerberos ticket has expired (e.g. because a machine was suspended for 24 hours and therefore the ticket was not refreshed automatically on time). Without the ability to ask for a password, the screensaver then cannot call pam_krb5 to renew the user's Kerberos ticket, and the user remains locked out in a deadlock situation. :-(

Both b) and c) are regular reasons for support requests in educational/corporate Linux environments with $HOME on Kerberized NFS.

The solution is simple. Instead of $HOME/.Xauthority, just use in future $XDG_RUNTIME_DIR/xauthority as the location of the X authority file. (In case $XDG_RUNTIME_DIR/ does not exist, /tmp/xauthority-$USER might be a suitable fallback option.)

According to https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html the $XDG_RUNTIME_DIR has all the right properties for holding the X authority file: it is always located in a local tmpfs filesystem, guaranteed to be accessible only to the current user, and will be wiped when the user has closed all sessions.

On modern Linux systems, pam_systemd usually creates XDG_RUNTIME_DIR=/run/user/$UID, and wipes it in the end.

(Note that according to https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html you should set the "sticky bit" on any files created in $XDG_RUNTIME_DIR whose timestamp is not updated regularly.)

Feature request: please provide an option for LightDM to do the equivalent of

  export XAUTHORITY=$XDG_RUNTIME_DIR/xauthority
  chmod +t $XAUTHORITY

and encourage Linux distribution maintainers to set this option by default, such that ~/.Xauthority is no longer used.

Changed in lightdm (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Markus Kuhn (markus-kuhn) wrote :

As a workaround, install the attached shell script as

  /etc/X11/Xsession.d/10local-xauthority

It uses xauth to merge ~/.Xauthority into $XDG_RUNTIME_DIR/xauthority and then updates XAUTHORITY to point at that location.

(Note that the "xauth merge" command will leave a warning such as "xauth: file /run/user/1597/xauthority does not exist" in ~/.xsession-errors.)

In the long run, it would of course be more elegant if LightDM (and other display managers) created the X authority file there in the first place.

Revision history for this message
Markus Kuhn (markus-kuhn) wrote :

While we are at it, we could probably also set

  ICEAUTHORITY=$XDG_RUNTIME_DIR/ICEauthority

in a similar fashion, as this is the equivalent cookie facility for X11 client-client communication.

Revision history for this message
Markus Kuhn (markus-kuhn) wrote :

see also bug 685194

Revision history for this message
Markus Kuhn (markus-kuhn) wrote :

LightDM is already able to create the xauthority file locally under $XDG_RUNTIME_DIR, using configuration option user-authority-in-system-dir. This option is off by default on Ubuntu 16.04/18.04, but can be enabled with

# echo -e '[LightDM]\nuser-authority-in-system-dir=true' >/etc/lightdm/lightdm.conf.d/50-user-authority-in-system-dir.conf

LightDM then sets XAUTHORITY=/var/run/lightdm/$USER/xauthority instead of $HOME/.Xauthority. However, this path goes through the symbolic link /var/run -> /run. For some reason (why?) snap does not like such symlinks, resulting in a warning:

# snap install pdftk
# pdftk
2018/08/24 17:32:48.267771 cmd_run.go:442: WARNING: XAUTHORITY environment value is not a clean path: "/run/lightdm/mgk25/xauthority"

A workaround to canonicalize the XAUTHORITY path (to eliminate symlinks) can be installed with e.g.

# echo 'XAUTHORITY=`readlink -f "$XAUTHORITY"` && [ -z "$XAUTHORITY" ] && export XAUTHORITY' >/etc/X11/Xsession.d/10canonicalize-xauthority

It would be nicer if LightDM directly used a canonical path in XAUTHORITY with user-authority-in-system-dir=true, or if snap didn't have to be so picky about symbolic links.

(LightDM currently does not set ICEAUTHORITY when user-authority-in-system-dir=true.)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.