<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - Users logging in gets previous user's XDG_RUNTIME_DIR" href="https://bugs.freedesktop.org/show_bug.cgi?id=62866#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED NOTOURBUG - Users logging in gets previous user's XDG_RUNTIME_DIR" href="https://bugs.freedesktop.org/show_bug.cgi?id=62866">bug 62866</a> from <a class="email" href="mailto:axs@gentoo.org" title="Ian Stakenvicius <axs@gentoo.org>"> Ian Stakenvicius</a> <pre>(In reply to <a href="show_bug.cgi?id=62866#c3">comment #3</a>) > Jeez. Not sure why I am even doing this, but here's the code of slim: > > <a href="http://git.berlios.de/cgi-bin/gitweb.cgi?p=slim;a=blob;f=app.cpp">http://git.berlios.de/cgi-bin/gitweb.cgi?p=slim;a=blob;f=app.cpp</a>; > h=b1b9d98d596505866d8a3bada8c90186c6a226e2;hb=HEAD > > If you check that out you will see that it reuses the PAM session process. > i.e. After the session is closed it simply restarts the main logic from the > same process. And that's what is not OK. It has to terminate it and run the > next login dialog from a new process. > Why, exactly? the PAM handle is closed and a new one initialized, what's the reason for the need of a new process? I also am unsure as to why resource limits, audit trails, etc. etc. should get messed up by slim not cycling its PID (in principle, that is) -- slim is one process that acts as a launcher only; the Xorg server and the client session are not re-used (and terminate prior to the next iteration)... I did trace why this (slim) is broken in systemd, and that's because logind is assuming that if the calling PID didn't change then a new session isn't necessary -- src/login/logind-dbus.c around line 487 or so. Just because gdm, kdm, perhaps xdm, etc., don't do this doesn't to me seem to make it invalid, but rather that the assumption of the same pid initiating two sessions (note, these are not at the same time) must therefore be a case of something like 'su' triggering the session code, is just too broad an assumption. Along these lines, it looks to me that this could be categorized as a bad cacheing issue -- when a session is closed (ie by the ReleaseSession handling code in src/login/logind-dbus.c around line 1731, as triggered by pam-module.c when pam_close_session is called), shouldn't it somehow be marked as such? That would allow the code just after the "if (session) {" in src/login/logind-dbus.c:488 to (re-)initialize the session rather than just re-use the old/incorrect session info that's already there. I realize changing this behaviour just for slim isn't something you're likely to do, but is it possible that this behaviour is still a bug that should be looked into?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>