Created attachment 41033 [details] [review]
In the old PolkitLockButton, can_obtain was defined as polkit_authorization_result_get_is_challenge() (see polkitlockbutton.c:783). In the new PolkitPermission, can_acquire is defined as polkit_authorization_result_get_retains_authorization() (see polkitpermission.c:509).
I'm sure there are good reasons for it, among others that GPermission shouldn't consider people can acquire a permission when it cannot be retained. But this triggers a bug in lock buttons. The implementation used but gnome-control-center's user-accounts shows the button as insensitive when g_permission_get_can_acquire() is FALSE. But for some reason, if you run a challenge and cancel it, g_permission_get_can_acquire() becomes FALSE.
t appears to be a bug in the interactive authority backend: it shouldn't consider can_acquire is FALSE in the case of user cancellation. Looking at the code, it seems it doesn't even consider adding this information in the result's details in case of failure.
So it seems we need a fix in polkitbackendinteractiveauthority.c:check_authorization_challenge_cb(), and maybe in check_authorization_sync(). I'm attaching a very ugly patch that fixes the issue for me, as a proof of concept.
I'm just realizing that g_permission_get_can_acquire() should return TRUE even if the permission cannot be retained, since programs will need to call this even before doing something that requires a one-shot authorization. So that would mean the current bug is only theoretical.
In that scheme, there's no way in GPermission to know whether an authorization can be retained, which means lock buttons will be shown even if it's meaningless (click->authenticate->lose authorization)...
(The lock button I'm talking about is at:
Hey, so, yeah, your patch is absolutely correct and fixes the problem. I've committed a patch that is somewhat similar:
Sorry for not looking at this before - I independently ran into the same problem and initially just blamed the lock button in
(In reply to comment #1)
> I'm just realizing that g_permission_get_can_acquire() should return TRUE even
> if the permission cannot be retained, since programs will need to call this
> even before doing something that requires a one-shot authorization. So that
> would mean the current bug is only theoretical.
> In that scheme, there's no way in GPermission to know whether an authorization
> can be retained, which means lock buttons will be shown even if it's
> meaningless (click->authenticate->lose authorization)...
> (The lock button I'm talking about is at:
Btw, if the authorization cannot be retained, then PolkitPermission will set can_acquire to FALSE and as a result the lock button (at least the one in https://bugzilla.gnome.org/show_bug.cgi?id=626457 which I believe is similar to the Control Center one) will show "Not authorized to make changes"
or similar. In fact, the Control Center just shows "Locked" with an useful tool tip (I manually edited the .policy file for the org.freedesktop.accounts.user-administration action to test this):
The bottom line is that PolkitPermission will not work with actions for which an authorization cannot be retained.
I was wondering if there is a workaround for this bug that won't involve rebooting or logging out of my desktop session?
(In reply to David Roundy from comment #4)
> I was wondering if there is a workaround for this bug that won't involve
> rebooting or logging out of my desktop session?
Not a reasonably secure one AFAICS. Are you quite sure that you are running into this 5-year old bug?