Bug 32334

Summary:	Always set polkit.retains_authorization_after_challenge
Product:	PolicyKit	Reporter:	Milan Bouchet-Valat <nalimilan>
Component:	daemon	Assignee:	David Zeuthen (not reading bugmail) <zeuthen>
Status:	RESOLVED FIXED	QA Contact:	David Zeuthen (not reading bugmail) <zeuthen>
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	Example patch

Description Milan Bouchet-Valat 2010-12-12 05:09:26 UTC

Created attachment 41033 [details] [review]
Example patch

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[1] 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.

Comment 1 Milan Bouchet-Valat 2010-12-12 05:29:01 UTC

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:
http://git.gnome.org/browse/gnome-control-center/tree/panels/user-accounts/um-lockbutton.c)

Comment 2 David Zeuthen (not reading bugmail) 2011-02-23 07:04:56 UTC

Hey, so, yeah, your patch is absolutely correct and fixes the problem. I've committed a patch that is somewhat similar:

 http://cgit.freedesktop.org/PolicyKit/commit/?id=135d8a3311f9d40087294e33bd199045bc401dd8

Sorry for not looking at this before - I independently ran into the same problem and initially just blamed the lock button in

 https://bugzilla.gnome.org/show_bug.cgi?id=642999

Comment 3 David Zeuthen (not reading bugmail) 2011-02-23 07:12:53 UTC

(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:
> http://git.gnome.org/browse/gnome-control-center/tree/panels/user-accounts/um-lockbutton.c)

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"

 http://people.freedesktop.org/~david/gtk-lock-button-with-non-retains.png

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):

 http://people.freedesktop.org/~david/control-center-with-non-retains.png

The bottom line is that PolkitPermission will not work with actions for which an authorization cannot be retained.

Comment 4 David Roundy 2016-05-03 16:43:29 UTC

I was wondering if there is a workaround for this bug that won't involve rebooting or logging out of my desktop session?

Comment 5 Miloslav Trmac 2016-05-04 15:05:07 UTC

(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?

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.