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: NEW
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
Depends on:
Reported: 2013-10-23 20:10 UTC by Gabriel Mainberger
Modified: 2013-11-18 18:19 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


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.


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.

# su - gabriel

(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 

This prevent GNOME to start.

Distribution bug reports:


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

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?

bug/show.html.tmpl processed on Mar 29, 2017 at 19:02:37.
(provided by the Example extension).