Comment 120 for bug 1197395

Hi everyone,

In Ubuntu, raring used libpam-xdg-support which was setting XDG_RUNTIME_DIR or not based on getuid(). In Saucy, it's changed to the systemd PAM module and the behaviour is different.

Say joe is user 1000, in raring his runtime directory was:

- /run/user/joe (when running an app)
- /home/joe/.cache (when running an app with sudo)
- /root/.cache (when running an app with gksu)
- /run/user/root (when running an app as root after an "su -")

In saucy, his runtime directory is:

- /run/user/1000 (when running an app)
- /home/joe/.cache (when running an app with sudo)
- /root/.cache (when running an app with gksu)
- /run/user/1000 (when running an app as root after an "su -")

As you can see it's the exact same (other than the fact that we've traded usernames for uids as required upstream) for every case except for "su -".

sudo seems to fall in a category where it's using the fallback... I wish it didn't write root files in the ~ dir, but at least that worked.

Before I go on further, let me say that I've no experience with systemd (this is all new to me), very little with PAM and I'm not here to have an opinion but to seek your advice.

It looks to me like systemd behaves the way it should but that breaks with the way things worked before. Is the solution either for systemd to set XDG_RUNTIME_DIR differently when the UID is 0, or for techs like glib and apps using this variable, to only rely on it when the UID isn't 0?

How should this be tackled by distributions between an upstream solution is adopted?

- Should we patch glib and individual apps to use a different runtime directory than XDG_RUNTIME_DIR when UID == 0?

- Should we patch the systemd PAM module to set XDG_RUNTIME_DIR with a different value based on the uid and not the loginuid?

We found a really hacky solution. Adding the following to /etc/profile sets XDG_RUNTIME_DIR the way the Ubuntu pam module used to set it in raring:

if [ "`id -u`" -eq 0 ]; then
  mkdir -p /run/user/0
  XDG_RUNTIME_DIR='/run/user/0'
fi

I hope I won't get laughed at for mentioning that hack :)

I'm sure you guys will work out a proper solution. In the meantime we need a fix or a workaround. This affects almost all distros out there, with apps crashing all over the place, desktops freezing, dconf, pulseaudio breaking etc..

Is the /etc/profile hack a bad workaround? Would it tackle all cases? Would there be issues in your opinion? Is it the worst idea you've read in a long time? or does it sound like a good temporary solution?

Thanks in advance for your expertise on this and good luck from us in agreeing on a solution.