[apparmor] [RFC] How should we deal with /tmp/xauth* ?

[Simon McVittie]

On Sun, 08 Jul 2018 at 14:55:35 +0300, Vincas Dargis wrote:
> > I suspect it is because other distros don't use xauth. For example,
> > Ubuntu uses 'server interpreted':
> > 
> > $ xhost
> > access control enabled, only authorized clients can connect
> > SI:localuser:jamie
> 
> Looks the same on Sid:
> 
> ```
> $ xhost
> access control enabled, only authorized clients can connect
> SI:localuser:vincas
> ```

Note that this might depend on your display manager (xdm, gdm, lightdm or
equivalent) as well as your distribution. I think gdm sets this up from
C code, independent of anything that might happen in /etc/X11/Xsession.d.

> Though sysdig shows some sort of zoo of variations, some applications uses
> `/tmp/xauth`, others $HOME/.Xauthority, and also there's
> `/home/vincas/.kde/tmp-vinco/xauth-1000-_0MT2492.new`

This is also application-specific. Anything that sets up an X11
session (a display manager like gdm or lightdm, distro scripts like
/etc/X11/Xsession.d, a nested X11 display like Xephyr or xvfb, a remoting
protocol implementation like xrdp or xpra, etc., and perhaps also desktop
sessions like gnome-session or startkde) can set up xauth authority
files according to its own designer's preference.

How they're set up is also dependent on the scope of the X server.
Historically, display managers normally started an X server as root for
the "greeter" (login prompt) and then recycled the same X server for the
user session that results from a login; but now that X does not always
need to run as root, some display managers (definitely including gdm,
possibly others) have started to use separate X servers for the greeter
and the user session.  This has implications for where the xauth authority
file is located (it must be visible to all uids that will share the X
server) and also for its file ownership (whether you can restrict the
AppArmor rule with "owner" or not).

    smcv