Bug#724731: XDG_RUNTIME_DIR has incorrect value
On 14/11/13 01:10, Leo Antunes wrote: I'm consistently getting the issue described by Gabriel Mainberger, namely that gdm gets the wrong XDG_RUNTIME_PATH and fails to start. But interestingly it only happens if I restart gdm. libpam-systemd derives the XDG_RUNTIME_PATH from the loginuid, which was originally part of the audit framework. The loginuid was originally intended to answer questions like yes, I know this process is root, but who is it really? to provide an audit trail: * /sbin/init has no loginuid (-1) * a process can change its loginuid from -1 to its own uid * otherwise, processes cannot change their loginuid * processes that handle an interactive login are expected to change the loginuid from -1 to the uid of the logged-in user Conceptually, system daemons like gdm, ssh, Apache, Exim ought to have loginuid -1: they're part of the OS, not a user (nobody logged in in order to use them). If a daemon handles logins (like gdm and ssh), this leaves it able to change its child's loginuid from -1 to the correct value. Under systemd (or probably Upstart too), this is fine: service(1) and similar tools just do IPC to init rather than launching the daemons themselves, and the new gdm is started by init, so it has loginuid -1 as desired. However, under sysvinit, there's no IPC interface by which this can happen, so invoke-rc.d/service/etc. start the daemon themselves. This results in the parent/child hierarchy conceptually being something like this: init \- getty or something: uid 0, loginuid -1 \- bash as root: uid 0, loginuid 0 \- invoke-rc.d: uid 0, loginuid 0 \- ... \- gdm: uid 0, loginuid 0 \- gnome-session: uid gdm3, loginuid 0 or: init \- getty or something: uid 0, loginuid -1 \- bash as a user: uid 1000, loginuid 1000 \- su: uid 0, loginuid 1000 \- invoke-rc.d: uid 0, loginuid 1000 \- ... \- gdm: uid 0, loginuid 1000 \- gnome-session: uid gdm3, loginuid 1000 Even after gdm daemonizes and re-parents to init, its loginuid remains. That's sort of the point of loginuid. (This sort of process environment leaking from parent to child situation is one of the reasons systemd/Upstart are better than the sysvinit + constellation of shell scripts approach to init...) The same thing breaks many tools when run under su (e.g. see https://bugzilla.redhat.com/show_bug.cgi?id=753882). There's some recent discussion on that bug: Ubuntu developers have been hit badly by it too. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724731: XDG_RUNTIME_DIR has incorrect value
Hi, On 14/11/13 13:57, Simon McVittie wrote: libpam-systemd derives the XDG_RUNTIME_PATH from the loginuid, which was originally part of the audit framework. The loginuid was originally intended to answer questions like yes, I know this process is root, but who is it really? to provide an audit trail: Thanks for the explanation. I wasn't aware of the rationale behind loginuid. The historical intention makes sense, but I don't get why logind should return XDG_RUNTIME_PATH based on this really real uid instead of the effective uid, since that's what's going to be used for permission control on the fs level. Am I missing something or do you mean to say this is a questionable decision? (...) Even after gdm daemonizes and re-parents to init, its loginuid remains. That's sort of the point of loginuid. Again, makes sense, but doesn't explain why XDG_RUNTIME_PATH must use loginuid. If loginuid's main reason for existence is auditing, I should still be able to see that my gdm was started by a su'd user 1000, but I want it to get /run/user/gdm's uid, since that's the process effective uid. Or more importantly, it seems really unintuitive (to say the least) that a request for session creation for an *explicitly given* UID should create a runtime dir for a different uid. But again, I may be missing something obvious. The same thing breaks many tools when run under su (e.g. see https://bugzilla.redhat.com/show_bug.cgi?id=753882). There's some recent discussion on that bug: Ubuntu developers have been hit badly by it too. If I understand you (and mentioned bug log) correctly, I guess this bug should be reassigned (or at least cloned over) to systemd then? Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724731: XDG_RUNTIME_DIR has incorrect value
[cc'ing systemd maintainers for their input] Hi all, On a fresh qemu install dist-upgraded to sid (wheezy install; dist-upgrade and lastly gnome install) I'm consistently getting the issue described by Gabriel Mainberger, namely that gdm gets the wrong XDG_RUNTIME_PATH and fails to start. But interestingly it only happens if I restart gdm. So it actually works on boot, but if I try to restart it, I get the following dbus calls from libpam-systemd: - method call sender=:1.59 - dest=org.freedesktop.login1 serial=2 path=/org/freedesktop/login1; interface=org.freedesktop.login1$Manager; member=CreateSession uint32 117 uint32 3462 string gdm-launch-environment string x11 string greeter string seat0 uint32 7 string string :0 boolean false string string array [ ] array [ ] boolean false method return sender=:1.17 - dest=:1.59 reply_serial=2 string 2 object path /org/freedesktop/login1/session/_32 string /run/user/1000 (dbus-monitor too dumb to decipher arg type 'h') string uint32 0 boolean true - Note that we're requesting a login for uid=117 and getting runtime_path=/run/user/1000. This is the result when run under su. The returned path is /run/user/0 if run directly by root. This doesn't seem to be impacted by the /proc/*/loginuid of systemd-logind (even if logind was started by a su'ed uid 1000, we still get /run/user/real uid when running gdm3 start). At first I wasn't sure where gnome-session was getting the wrong XDG_RUNTIME_PATH, so I attempted calling env - /usr/sbin/service gdm3 restart, but this changed nothing. Incidently, this system is also affected by #728180, so maybe the fact that I had to kill Xorg (and with it gnome-session) after stopping gdm3 might have something to do with it? I'm not sure if this is a problem with gdm3, gnome-session or systemd-logind, and I'm unfortutately stumped as to ways of debugging this better. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724731: XDG_RUNTIME_DIR has incorrect value
Same issue for me after upgrading to gdm 3.8.4-3. A black screen after starting gdm, except if I chmod 777 /run/user/0. /var/log/gdm3/:0-slave.log: gdm-simple-slave[5325]: Failed to give slave programs access to the display. Trying to proceed. gdm-launch-environment][5358]: pam_env(gdm-launch-environment:session): Unable to open env file: /etc/environment: Datei oder Verzeichnis nicht gefunden gdm-launch-environment][5358]: pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by (uid=0) gdm-launch-environment][5358]: pam_systemd(gdm-launch-environment:session): Asking logind to create session: uid=115 pid=5358 service=gdm-launch-environment type=x11 class=greeter seat=seat0 vtnr=7 tty= display=:0 remote=no remote_user= remote_host= gdm-launch-environment][5358]: pam_systemd(gdm-launch-environment:session): Reply from logind: id=c1 object_path=/org/freedesktop/login1/session/c1 runtime_path=/run/user/0 session_fd=13 seat=seat0 vtnr=1 gdm-launch-environment][5358]: pam_ck_connector(gdm-launch-environment:session): nox11 mode, ignoring PAM_TTY :0 gdm3][5591]: pam_env(gdm3:session): Unable to open env file: /etc/environment: Datei oder Verzeichnis nicht gefunden gdm3][5591]: pam_unix(gdm3:session): session opened for user gabriel by (uid=0) 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 gdm3][5591]: pam_ck_connector(gdm3:session): nox11 mode, ignoring PAM_TTY :0 gdm-launch-environment][5358]: pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm gdm-simple-slave[5325]: Failed to remove slave program access to the display. Trying to proceed. gdm-simple-slave[5325]: Child process -5369 was already dead. gdm3][5591]: pam_unix(gdm3:session): session closed for user gabriel gdm-simple-slave[5325]: GLib-GObject: g_object_ref: assertion `object-ref_count 0' failed gdm-simple-slave[5325]: GLib-GObject: g_object_unref: assertion `object-ref_count 0' failed If I login with my user account, I still get the wrong runtime_path. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724731: XDG_RUNTIME_DIR has incorrect value
What's your $XDG_RUNTIME_DIR environment variable? My $XDG_RUNTIME_DIR as user gabriel (uid=1000) is /run/user/0 and should in my opinion be /run/user/1000. If it's /run/user/0, then GLib is behaving as expected, and the bug is in some other component (which should either not set this variable, unset this variable when it switches uid, or set this variable to a more appropriate value for uid 1000). I agree that Glib is working correctly. user@machine:~/Work$ echo $XDG_RUNTIME_DIR /run/user/0 user@machine:~/Work$ ./run /run/user/0 user@machine:~/Work$ XDG_RUNTIME_DIR=/run/user/1000 user@machine:~/Work$ export XDG_RUNTIME_DIR user@machine:~/Work$ echo $XDG_RUNTIME_DIR /run/user/1000 user@machine:~/Work$ ./run /run/user/1000 user@machine:~/Work$ unset XDG_RUNTIME_DIR user@machine:~/Work$ ./run /home/gabriel/.cache What seems related is the but in gdm3 which fails to start when libpam-systemd is not installed [1]. libpam-systemd is responsible for creating and setting XDG_RUNTIME_DIR. So I assume Gabriel didn't have this package installed. Is that correct? No, libpam-systemd is installed correctly on my system. user@machine:~/Work$ dpkg -s libpam-systemd Package: libpam-systemd Status: install ok installed Priority: optional Section: admin Installed-Size: 64 Maintainer: Debian systemd Maintainers pkg-systemd-maintain...@lists.alioth.debian.org Architecture: i386 Multi-Arch: same Source: systemd Version: 204-5 So from a cursory look, it seems like glib is behaving correctly and as Simon suspects, some other component simply sets XDG_RUNTIME_DIR to an incorrect value. I agree. Some other relevant info: * is this in X11 or at a text virtual console? This is in X11. * if in X11, which display manager (gdm3, lightdm, xdm, kdm, etc.), or did you use startx or something from a text virtual console? Currently I get with gdm3 only a black screen. So my only possibility is to chmod my /run/user/0 directory. Switch with su - gabriel to my account and execute startx. * are you using systemd or sysvinit as your init (process 1)? # ps ax PID TTY STAT TIME COMMAND 1 ?Ss 0:01 init [2] Should be the good old sysvinit. Never changed to systemd. * which PAM modules do you have (dpkg-query -W 'libpam*'), and have you reconfigured the PAM stack or are you using defaults? # dpkg-query -W 'libpam*' libpam-cap:i386 1:2.22-1.2 libpam-ck-connector:i3860.4.6-3+b1 libpam-dev libpam-doc libpam-gnome-keyring3.8.2-2 libpam-mkhomedir libpam-modules:i386 1.1.3-10 libpam-modules-bin 1.1.3-10 libpam-motd libpam-mount libpam-runtime 1.1.3-10 libpam-smbpass libpam-ssh libpam-systemd:i386 204-5 libpam-umask libpam0g:i386 1.1.3-10 libpam0g-dev:i386 1.1.3-10 libpam0g-util I have found out, if I do login on tty1 and stop gdm3. And do a login on tty2 direct as user the XDG_RUNTIME_DIR variable is set correctly /run/user/1000. I can start X with the command startx without any changes. But if I switch the user from root with su - gabriel the XDG_RUNTIME_DIR variable remains on /run/user/0. This could may be an issue for gdm3, when switching user context. Changed in file /etc/pam.d/common-session session optionalpam_systemd.so to session optionalpam_systemd.so debug=1 Set following output in /var/log/auth.log Oct 23 15:08:03 machine su[5608]: Successful su for gabriel by root Oct 23 15:08:03 machine su[5608]: + /dev/tty1 root:gabriel Oct 23 15:08:03 machine su[5608]: pam_env(su:session): Unable to open env file: /etc/environment: Datei oder Verzeichnis nicht gefunden Oct 23 15:08:03 machine su[5608]: pam_unix(su:session): session opened for user gabriel by root(uid=0) Oct 23 15:08:03 machine su[5608]: pam_systemd(su:session): Asking logind to create session: uid=1000 pid=5608 service=su type=tty class=user seat=seat0 vtnr=1 tty=/dev/tty1 display= remote=no remote_user=root remote_host= Oct 23 15:08:03 machine su[5608]: pam_systemd(su:session): Reply from logind: id=c1 object_path=/org/freedesktop/login1/session/c1 runtime_path=/run/user/0 session_fd=6 seat=seat0 vtnr=1 Oct 23 15:09:01 machine CRON[5680]: pam_env(cron:session): Unable to open env file: /etc/environment: Datei oder Verzeichnis nicht gefunden The runtime_path is set to /run/user/0. Don't know if this is correct or wrong. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724731: XDG_RUNTIME_DIR has incorrect value
On 23/10/13 14:17, Gabriel Mainberger wrote:
* if in X11, which display manager (gdm3, lightdm, xdm, kdm, etc.),
or did you use startx or something from a text virtual console?
Currently I get with gdm3 only a black screen. So my only possibility is
to chmod my /run/user/0 directory.
Making /run/user/${UID} writable by users other than ${UID} is probably
a security vulnerability, so I would advise not doing that.
Oct 23 15:08:03 machine su[5608]: pam_unix(su:session): session opened
for user gabriel by root(uid=0)
Oct 23 15:08:03 machine su[5608]: pam_systemd(su:session): Asking logind
to create session: uid=1000 pid=5608 service=su type=tty class=user
seat=seat0 vtnr=1 tty=/dev/tty1 display= remote=no remote_user=root
remote_host=
Oct 23 15:08:03 machine su[5608]: pam_systemd(su:session): Reply from
logind: id=c1 object_path=/org/freedesktop/login1/session/c1
runtime_path=/run/user/0 session_fd=6 seat=seat0 vtnr=1
That doesn't look right - shouldn't systemd-logind be returning
/run/user/1000 here? This might be a systemd-logind bug.
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724731: XDG_RUNTIME_DIR has incorrect value
On 23.10.2013 16:18, Simon McVittie wrote:
Making /run/user/${UID} writable by users other than ${UID} is probably
a security vulnerability, so I would advise not doing that.
If course not. This is only a workaround to get X working again. But
login direct as user avoid this workaround anyway.
Oct 23 15:08:03 machine su[5608]: pam_unix(su:session): session opened
for user gabriel by root(uid=0)
Oct 23 15:08:03 machine su[5608]: pam_systemd(su:session): Asking logind
to create session: uid=1000 pid=5608 service=su type=tty class=user
seat=seat0 vtnr=1 tty=/dev/tty1 display= remote=no remote_user=root
remote_host=
Oct 23 15:08:03 machine su[5608]: pam_systemd(su:session): Reply from
logind: id=c1 object_path=/org/freedesktop/login1/session/c1
runtime_path=/run/user/0 session_fd=6 seat=seat0 vtnr=1
That doesn't look right - shouldn't systemd-logind be returning
/run/user/1000 here? This might be a systemd-logind bug.
The same behavior is described in this case:
https://bugzilla.redhat.com/show_bug.cgi?id=753882
In my opinion this is a bug from systemd. Of course
su user
should preserve the environment variables, but
su - user
not.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#724731: XDG_RUNTIME_DIR has incorrect value
Created a bug report for systemd. https://bugs.freedesktop.org/show_bug.cgi?id=70810. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
