File: /lib/i386-linux-gnu/security/pam_systemd.so Version: Version: 204-5 Debian-Package: libpam-systemd After the specification the user runtime directory must be accessible by the user. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables But it seams to be an distribution independent behavior, that the XDG_RUNTIME_DIR variable is not changed in case of su is switching the context. # echo $XDG_RUNTIME_DIR /run/user/0 # su - gabriel $ echo $XDG_RUNTIME_DIR /run/user/0 (Which should be "/run/user/1000") This does result in access deny messages, because a normal user does not have access to the root runtime directory. GNOME has started using user runtime dir, which is set by the environment variable XDG_RUNTIME_DIR. (gnome-settings-daemon:7139): dconf-CRITICAL **: unable to create directory '/run/user/0/dconf': Permission denied. doconf will not work properly. This prevent GNOME to start. Distribution bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=753882 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724731 In my opinion this is a bug in pam_systemd.so. Of course su user should preserve the XDG_RUNTIME_DIR variable, but su - user should not. In case of login direct as user, the XDG_RUNTIME_DIR is set correct.
/var/log/gdm3/:0-slave.log: gdm3][5591]: pam_systemd(gdm3:session): Asking logind to create session: uid=1000 pid=5591 service=gdm3 type=x11 class=user seat=seat0 vtnr=7 tty= display=:0 remote=no remote_user= remote_host= gdm3][5591]: pam_systemd(gdm3:session): Reply from logind: id=c1 object_path=/org/freedesktop/login1/session/c1 runtime_path=/run/user/0 session_fd=15 seat=seat0 vtnr=1 It doesn't make sense for user uid=1000 to have a runtime_path=/run/user/0.
If getting the struct passwd * allways by username, it is working with su. src/login/pam-module.c:166:static int get_user_data /*r = audit_loginuid_from_pid(0, &uid); if (r >= 0) pw = pam_modutil_getpwuid(handle, uid); else {*/ r = pam_get_user(handle, &username, NULL); Oct 27 08:40:11 andromeda su[8585]: pam_unix(su:session): session closed for user root Oct 27 08:40:16 andromeda su[8601]: Successful su for root by gabriel Oct 27 08:40:16 andromeda su[8601]: + /dev/pts/2 gabriel:root Oct 27 08:40:16 andromeda su[8601]: pam_unix(su:session): session opened for user root by gabriel(uid=1000) Oct 27 08:40:16 andromeda su[8601]: pam_systemd(su:session): Asking logind to create session: uid=0 pid=8601 service=su type=tty class=user seat=seat0 vtnr=7 tty=/dev/pts/2 display= remote=no remote_user=gabriel remote_host= Oct 27 08:40:16 andromeda su[8601]: pam_systemd(su:session): Reply from logind: id=2 object_path=/org/freedesktop/login1/session/_32 runtime_path=/run/user/1000 session_fd=6 seat=seat0 vtnr=7 Oct 27 08:42:31 andromeda su[8601]: pam_unix(su:session): session closed for user root The runtime_path is still wrong, but the correct uid is overgiven. Is there any reason to use the function audit_loginuid_from_pid?
See https://bugzilla.redhat.com/show_bug.cgi?id=753882 http://lists.freedesktop.org/archives/systemd-devel/2013-November/014370.html
Let's close this one. Since a long time, after an "su" $XDG_RUNTIME_DIR is simply not passed anymore, which should fix the issue, as we'll never pass the wrong one, just sometimes none.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.