Bug 32334 - Always set polkit.retains_authorization_after_challenge
Summary: Always set polkit.retains_authorization_after_challenge
Status: RESOLVED FIXED
Alias: None
Product: PolicyKit
Classification: Unclassified
Component: daemon (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: David Zeuthen (not reading bugmail)
QA Contact: David Zeuthen (not reading bugmail)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-12 05:09 UTC by Milan Bouchet-Valat
Modified: 2016-05-04 15:05 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Example patch (1.58 KB, patch)
2010-12-12 05:09 UTC, Milan Bouchet-Valat
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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.