Bug 70810

Summary: libpam-systemd does not change XDG_RUNTIME_DIR when using su - username
Product: systemd Reporter: Gabriel Mainberger <gabisoft>
Component: generalAssignee: Zbigniew Jedrzejewski-Szmek <zbyszek>
Status: RESOLVED FIXED QA Contact: systemd-bugs
Severity: normal    
Priority: high CC: pochu27
Version: unspecified   
Hardware: All   
OS: All   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=753882
Whiteboard:
i915 platform: i915 features:

Description Gabriel Mainberger 2013-10-23 20:10:43 UTC 
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.
Comment 1 Gabriel Mainberger 2013-10-25 07:26:34 UTC 
/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.
Comment 2 Gabriel Mainberger 2013-10-27 08:00:28 UTC 
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?
Comment 4 Lennart Poettering 2018-08-08 15:32:10 UTC 
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.