Skip to content

gdm-session-worker: Ask logind for the login screen

Iain Lane requested to merge wip/iainl/user-switching-logind-tty into master

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)

Edited by Iain Lane

Merge request reports

Loading