Bug 70810 - libpam-systemd does not change XDG_RUNTIME_DIR when using su - username
Summary: libpam-systemd does not change XDG_RUNTIME_DIR when using su - username
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All All
: high normal
Assignee: Zbigniew Jedrzejewski-Szmek
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-23 20:10 UTC by Gabriel Mainberger
Modified: 2018-08-08 15:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.