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. ** Attachment added: "/etc/X11/Xsession.d/10local-xauthority" https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1648107/+attachment/4789021/+files/local-xauthority -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1648107 Title: $XAUTHORITY should move into $XDG_RUNTIME_DIR Status in lightdm package in Ubuntu: Triaged 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1648107/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
