Comment 124 for bug 1197395

(In reply to Richard W.M. Jones from comment #54)
> The problem is the exact opposite of this. When someone is root
> and 'su -' to a user, XDG_RUNTIME_DIR still points to the root-owned
> directory and so is unusable by applications.

It works both ways -- in both cases the program you run under su gets an $XDG_RUNTIME_DIR which isn't owned by the target user, which either (1) results in EPERM issues (for "su user" from root) or (2) hijacking files and changing their owner (for "su -" from user).

> I am recommending that no one uses XDG_RUNTIME_DIR at all since you
> cannot be sure it exists and has usable permissions.

The idea is fine in general, it's just that due to this pam_systemd bug it doesn't promise what it says in the specification ("directory MUST be owned by the user").

Taking Lennart's concerns into account, I think an acceptable compromise would be for pam_systemd to unset $XDG_RUNTIME_DIR if it already exists but isn't owned by geteuid(). Then the program you run under su won't use a wrong runtime dir any more, but also doesn't pretend to be a full session.

(In reply to Matthias Clasen from comment #55)
> su is the problem, not XDG_RUNTIME_DIR.

It's not -- su has nothing to do with $XDG_* stuff. It's just running the standard PAM modules.

For the record, David proposed a workaround for pulse in http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-November/019121.html, but that would need to be applied to dconf, dbus, and everything else that uses $XDG_RUNTIME_DIR. That's just wrong, this check should be done in the pam_systemd dir.