After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 753181 - when switching to login screen, user session terminates
when switching to login screen, user session terminates
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: login-screen
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Ray Strode [halfline]
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2015-08-03 13:54 UTC by Ray Strode [halfline]
Modified: 2015-08-05 13:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdm: make user list fade-in on vt switch more reliable (5.34 KB, patch)
2015-08-04 14:44 UTC, Ray Strode [halfline]
committed Details | Review
gdm: clear user verifier when finished with it (2.42 KB, patch)
2015-08-04 14:44 UTC, Ray Strode [halfline]
committed Details | Review

Description Ray Strode [halfline] 2015-08-03 13:54:39 UTC
From https://mail.gnome.org/archives/gnome-shell-list/2015-August/msg00000.html :

Previously if I was logged and I ctrl+alt+f1, gdm would offer to unlock
my session. This was misleading since my session was not really locked.
I could ctrl+alt+f3 and continue working.

After the checkins on 2015-07-24 to gnome-3-16 branch, the behavior
changed. It not longer offers to unlock after ctrl+alt+f1 (which fixes
the misleading behavior or privacy issue).

But if I log on to the same user, it terminates the existing session
and starts a new one without telling me that it terminated the old
session.
Comment 1 Ray Strode [halfline] 2015-08-03 13:55:41 UTC
irc discussion:

<grawity> hmm, why would gdm think "session was cancelled" http://sprunge.us/YRUL
<halfline> grawity: weird
<grawity> that happens exactly when I switch from my own gnome to tty1 (but not any other combination)
<grawity> 3.17.4
<halfline> lemme dig for a sec
<halfline> grawity: do you have wayland disabled ?
<halfline> for the login screen
<ebassi> halfline: There was something like that on gnome-shell-list recently
<ebassi> https://mail.gnome.org/archives/gnome-shell-list/2015-August/msg00000.html
<halfline> oh thanks
<grawity> usually it's on, but happens with both
<halfline> probably caused by this commit https://git.gnome.org/browse/gnome-shell/commit/?id=3c8c5a5570592b2a45c7e02823e1812680a16d87
<halfline> but need to dig more to find out why
<halfline> so what's happening is, the login screen fades out after the user successfully logs in
<halfline> then when they switch vt's back it resets and fades back in
<halfline> part of the resetting process involves canceling the user verifier that was set before
<halfline> the user verifier has an "embryonic session" associated with it before verification succeeds
<halfline> so normally when you cancel the user verifier it cancels that session too
<halfline> in this case the embryonic session has grown into a full blown running session
<halfline> but it's still associated with the user verifier
<halfline> so cancelling the user verifier is cancelling the session
<halfline> before https://git.gnome.org/browse/gnome-shell/commit/?id=3c8c5a5570592b2a45c7e02823e1812680a16d87 it would only cancel the user verifier if the user verifier was well verifying
<halfline> but now it cancels it unconditionally
<halfline> so there's a number of fixes we could do here
<halfline> the first would be we could change the if (this._userVerifier) to if (this._userVerifier && AuthPromptStatus.VERIFICATION_COMPLETE)
<halfline> the second is we could dissociate the user verifier from the session object once it's no longer embryonic
<halfline> the third is we could dissociate the user verifier from the login screen once verification succeeds
<halfline> i think maybe some combination of the above is the right way to go
<halfline> essentially, though, this comment in the commit message was wrong "The object already handles getting called when there is nothing to cancel, so just cancel it unconditionally."
<halfline> i'll file a bug with some fixes in a bit
Comment 2 Ray Strode [halfline] 2015-08-04 14:44:06 UTC
Created attachment 308744 [details] [review]
gdm: make user list fade-in on vt switch more reliable

We fade out the authentication prompt when a user successfully
logs into a user session. We reset it and fade it back in when
the user switches back to the login screen VT.

The problem is, we only fade it back in if the auth prompt status is
VERIFICATION_SUCCEEDED.  It's possible for it to be NOT_VERIFYING
if the authprompt gets reset for some other reason in the interim.

This commit changes the check to be more precise. We now only skip
the fade-in, if we're already faded in, and we only skip the reset if
we're already reset.
Comment 3 Ray Strode [halfline] 2015-08-04 14:44:11 UTC
Created attachment 308745 [details] [review]
gdm: clear user verifier when finished with it

We only need the user verifier for the purpose of user verification.
Once it's complete we should clear it so it doesn't get in the way
later.

This fixes a bug introduced in commit 3c8c5a557059 that leads to the
user session crashing when the login screen is reactivated.
Comment 4 Jasper St. Pierre (not reading bugmail) 2015-08-05 03:07:33 UTC
Review of attachment 308745 [details] [review]:

OK.
Comment 5 Ray Strode [halfline] 2015-08-05 13:43:30 UTC
Attachment 308744 [details] pushed as 02c6b03 - gdm: make user list fade-in on vt switch more reliable
Attachment 308755 [details] pushed as 08506ea - gdm: clear user verifier when finished with it