[systemd-bugs] [Bug 62866] Users logging in gets previous user's XDG_RUNTIME_DIR

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62866

--- Comment #4 from Ian Stakenvicius <axs at gentoo.org> ---
(In reply to comment #3)
> Jeez. Not sure why I am even doing this, but here's the code of slim:
> 
> http://git.berlios.de/cgi-bin/gitweb.cgi?p=slim;a=blob;f=app.cpp;
> 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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20131023/efaf8077/attachment.html>