GNOME Bugzilla – Bug 680750
Occasional lock-screen brokenness
Last modified: 2013-01-03 01:01:27 UTC
I occasionally see the following: After raising the screenshield, - text typed into the password entry appears in cleartext - the unlock button remains insensitive (and enter obviously does not work either) - clicking "sign in as another user" will shortly reveal the user session before ending again with the screenshield The following .xsession-errors looks relevant: JS ERROR: !!! Exception was: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Can only be called before user is logged in JS ERROR: !!! message = '"GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Can only be called before user is logged in"' JS ERROR: !!! fileName = '"/home/florian/src/gnome-shell/js/gdm/util.js"' JS ERROR: !!! lineNumber = '145' JS ERROR: !!! stack = '"0 anonymous("result" = [object _private_Gio_SimpleAsyncResult], "client" = [object _private_Gdm_Client])@/home/florian/src/gnome-shell/js/gdm/util.js:145 1 wrapper([object _private_Gdm_Client], [object _private_Gio_SimpleAsyncResult])@/home/florian/opt/gnome/share/gjs-1.0/lang.js:204 "'
Ok, so the AccessDenied is because in line 138 of gdm/util.js we catch all errors from OpenReauthenticationChannel and silently fallback to GetUserVerifier, which is ok for the login session, but obviously fails for the unlock dialog.
Created attachment 220251 [details] [review] GdmUtil: don't call GetUserVerifier from the user session GetUserVerifier can only be called from the greeter session, and fails with AccessDenied in all other cases. Also, calling it hides the real error from OpenReauthenticationChannel, which instead should be logged.
Review of attachment 220251 [details] [review]: ::: js/gdm/util.js @@ +144,3 @@ + + this._hold.release(); + this.emit('verification-failed'); Did you forget a return; or an else or something?
The other bug (the entry in plain text and the confirm button insensitive) is because the pam conversation is async, and we don't know if the entry is a password or not until told by gdm. One possible fix is to hide the entry until we're ready.
Created attachment 220253 [details] [review] GdmUtil: don't call GetUserVerifier from the user session GetUserVerifier can only be called from the greeter session, and fails with AccessDenied in all other cases. Also, calling it hides the real error from OpenReauthenticationChannel, which instead should be logged. Sorry, attached too soon.
Review of attachment 220253 [details] [review]: Makes sense to me.
Attachment 220253 [details] pushed as 48b70f3 - GdmUtil: don't call GetUserVerifier from the user session
This was not really fixed...
Updating component.
I believe all the original issues are fixed in 3.6, closing.