GNOME Bugzilla – Bug 708187
polkit dialogs displayed while screen is locked show in "fallback" rather than "shell" mode or show over the screen lock
Last modified: 2013-09-23 11:34:06 UTC
Normally polkit authorisation requests are shown in the "gnome-shell" way (i.e. nice and black and centered). If however, the screen is locked, one of two things seems to happen. 1. If the authentication is a simple pkexec wrapper script, the g-s auth dialog seems to show over the lock screen and functions correctly (e.g. entering the auth credentials works and the program is run (albeit behind the screen shield hidden from view). or 2. The authentication dialog shows, but is hidden behind the lock (which is what I'd expect) but when unlocking rather than getting the nice "gnome-shell" version of the dialog, an older looking gtk dialog shows instead. The former behaviour can be replicated with a simple sleep 10; pkexec /foo/bar (with appropriate .policy file in place) and then locking the screen via the menu. The latter behaviour "just happens" for me with an online account (google) which seems to request periodic authentication (but never actually works!). So not sure how to reproduce this behaviour. If you need more debug, please shout and I can try and extract it.
Ok, so, the second one is not a polkit dialog, it's gnome-keyring, which for some reason uses the fallback dialog when the shell is not registered as a prompter (such as when locked). As for the first one, what should happen is that the authentication fails straight away (not auth agent available). But it seems polkit is always enabled, and it has been this way since the beginning.
Excellent sleuthing Giovanni! That makes much more sense now as to why there was a difference in behaviour (to be honest I was only really "reporting" the gnome-keyring based problem initially and then tried to replicate it with a simple pkexec and discovered the equally odd, but different, behaviour there. Do you think both can/should be fixed and if so would you like me to report the polkit one separately?
Created attachment 255241 [details] [review] keyring: Manually dispose the prompt if open fails The keyring dialog can only handle a single request, e.g. we rely on each request creating a new prompt. Normally when the dialog is closed, the corresponding prompt is destroyed as well, so a new one will be created for the next request. However this fails when we fail to show the dialog in the first place, as the prompt will stick around indefinitively after cancelling.
Created attachment 255242 [details] [review] keyring: Don't unregister the prompt when disabled gnome-keyring provides a fallback in case our builtin prompt fails to register, so keyring dialogs may still pop up even when they are supposed to be disabled. Instead, keep the prompt registered but cancel requests immediately while disabled.
Review of attachment 255241 [details] [review]: OK.
Review of attachment 255242 [details] [review]: ::: js/ui/components/keyring.js @@ +231,3 @@ + this.prompt.connect('show-password', Lang.bind(this, this._cancelPrompt)); + this.prompt.connect('show-confirm', Lang.bind(this, this._cancelPrompt)); + this.prompt.connect('prompt-close', function() {}); What's the point of this one? Can't we just not connect to the signal at all?
(In reply to comment #3) > Created an attachment (id=255241) [details] [review] > keyring: Manually dispose the prompt if open fails Uhm, looking at the code, run_dispose() does little more than cancel(). What is the difference here? And why does ShellKeyringPrompt not close() prompt unless shown? Oh wait, why isn't ShellKeyringPrompt chaining up from prompt_close()?
(In reply to comment #7) > Oh wait, why isn't ShellKeyringPrompt chaining up from prompt_close()? Chaining up to what? ShellKeyringPrompt inherits from GObject ...
(In reply to comment #6) > What's the point of this one? Can't we just not connect to the signal at all? Yeah, that's some left-over code. Removed locally.
(In reply to comment #8) > (In reply to comment #7) > > Oh wait, why isn't ShellKeyringPrompt chaining up from prompt_close()? > > Chaining up to what? ShellKeyringPrompt inherits from GObject ... Mh, I thought it was a GcrSystemPrompt. Then the differences between cancel() and run_dispose() are even smaller.
(In reply to comment #10) > Then the differences between cancel() and run_dispose() are even smaller. If you mean we could use run_dispose() instead of cancel(), then yeah, that should work.
Created attachment 255481 [details] [review] shell: Make KeyringPrompt.cancel() callable from signal handlers gcr/gnome-keyring don't handle the case where prompt_password_async()/ prompt_confirm_async() return their result from within the function very well (or rather: break badly). Calling gcr_prompt_close() instead is safe, but to avoid these kind of errors in the future, modify shell_keyring_prompt_cancel() to work as expected in this case.
Created attachment 255482 [details] [review] keyring: Don't unregister the prompt when disabled OK, next take ...
Review of attachment 255481 [details] [review]: We should maybe move to GTask, which handles this transparently, but yes, this is fine for 3.10
Review of attachment 255482 [details] [review]: Ok
Attachment 255481 [details] pushed as a89fd17 - shell: Make KeyringPrompt.cancel() callable from signal handlers Attachment 255482 [details] pushed as 1242a16 - keyring: Don't unregister the prompt when disabled