gdm-session-worker: Ask logind for the login screen
When a session ends, its "session worker" is closed. Since 3e822092 (3.33.4), we uninitialise PAM when this happens. As part of this procedure, we jump back to the login screen, if the screen being killed is not itself the login screen.
This has broken fast user switching. It goes like this - this explanation is a bit complicated, bear with us:
We want to jump back to the login screen when a normal user session
ends, so that people can log in again. We do not want to do this when a
login screen itself ends. When session workers start up, they query for
the currently active VT and save this in login_vt
. Then later on, we
check if our session ID is the same as login_vt
, and jump to
login_vt
if they are different - this means that it was a user session
not a login session. Querying the currently active VT is fine for the
first greeter, but when initiating a user switch it's wrong as this
gives the user VT.
GDM greeters are killed once they have spawned a session. They are
associated with a logind session, and therefore a PAM session. There are
some actions performed when unregistering PAM sessions, including the
previously mentioned VT jump. Before
3e822092 we only uninitialised PAM when
the session itself exited so the bug was masked, but now (since this
commit), if the login screen's worker exits first - as happens in the
normal case when GDM kills it - we also do this uninitialisation. Since
we falsely recorded the login screen as the first user's VT, this means
that checking login_vt != session_vt
returns TRUE
and we jump back
to the previous user's session immediately after logging into the new
session: fast user switching is broken.
What we need to do instead is query logind to determine the actual VT in
use for the login screen, rather than assuming it is the one which
started the session. We only know the VT after we have started the PAM
session, though, so we need to move the location where we retrieve the
VT to just after PAM initialisation. There's a place where we
temporarily set the PAM_TTY
PAM variable which happens before we open
PAM too - keep this as the current VT. This is reset after we've opened
the PAM session, so it is OK for it to be temporarily wrong.
Closes #515 (closed)