Bug 30653 - No way to detect cancellation in pkexec
Summary: No way to detect cancellation in pkexec
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-10-06 06:08 UTC by Bastien Nocera
Modified: 2011-02-22 16:35 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bastien Nocera 2010-10-06 06:08:52 UTC
We should be told that the command was cancelled, not be obnoxious about it.

$ pkexec /usr/sbin/gnome-display-properties-install-systemwide 
Error executing command as another user: Not authorized

This incident has been reported.
Comment 1 David Zeuthen (not reading bugmail) 2011-02-22 08:13:33 UTC
Not inherently opposed, but the problem here is to communicate the fact that the request was cancelled. From the man page

 RETURN VALUE
        Upon successful completion, the return value is the return value of
        PROGRAM. If the calling process is not authorized or an authorization
        could not be obtained through authentication or an error occured,
        pkexec exits with a return value of 127.

We probably could exit with code 126 if the request cancelled.
Comment 2 Bastien Nocera 2011-02-22 11:20:33 UTC
(In reply to comment #1)
> Not inherently opposed, but the problem here is to communicate the fact that
> the request was cancelled. From the man page
> 
>  RETURN VALUE
>         Upon successful completion, the return value is the return value of
>         PROGRAM. If the calling process is not authorized or an authorization
>         could not be obtained through authentication or an error occured,
>         pkexec exits with a return value of 127.
> 
> We probably could exit with code 126 if the request cancelled.

That would be fine with me.
Comment 3 David Zeuthen (not reading bugmail) 2011-02-22 11:44:14 UTC
Another problem is how the Authentication Agent should convey to the Authority that the authentication dialog was actually dismissed by the user (I guess this is what you mean by "cancellation").

It should probably do this by returning the error org.freedesktop.PolicyKit1.Error.RequestDismissed in response to the BeginAuthentication() method call.

And then we need to figure out that this is conveyed back to the Mechanism. We should probably have a is_dismissed() method on the PolkitAuthorizationResult object.

With this, it should be pretty straight-forward to make the pkexec(1) Mechanism do what you want.
Comment 4 David Zeuthen (not reading bugmail) 2011-02-22 11:47:59 UTC
Btw, why do you need this? I guess you want to do nothing if the auth dialog was dismiss and complain with a GtkDialog or similar on other errors?
Comment 5 Bastien Nocera 2011-02-22 12:09:28 UTC
The various "unlock" buttons in the control-center need to stay sensitive if the authorisation was cancelled (as opposed to auth failure), and pkexec shouldn't be nasty when auth is cancelled: https://bugzilla.gnome.org/show_bug.cgi?id=631078
Comment 6 David Zeuthen (not reading bugmail) 2011-02-22 12:20:28 UTC
(In reply to comment #5)
> The various "unlock" buttons in the control-center need to stay sensitive if
> the authorisation was cancelled (as opposed to auth failure), 

Interesting. Why shouldn't the unlock buttons stay sensitive even on auth failure? I mean, it could be the user just inputs the wrong password... [1]

IIRC the proposed GtkLockButton does the right thing (see https://bugzilla.gnome.org/show_bug.cgi?id=626457 ) in this case...


[1] : FWIW, gnome-shell's polkit agent (that I pushed just a minute ago!) will only give you one attempt to get the password right (as opposed to polkit-gnome that will give you three attempts)
Comment 7 Bastien Nocera 2011-02-22 12:34:58 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > The various "unlock" buttons in the control-center need to stay sensitive if
> > the authorisation was cancelled (as opposed to auth failure), 
> 
> Interesting. Why shouldn't the unlock buttons stay sensitive even on auth
> failure? I mean, it could be the user just inputs the wrong password... [1]

Huh. I got this wrong. It would try and show an error in some cases (see the "make default" case).
Comment 8 David Zeuthen (not reading bugmail) 2011-02-22 12:41:01 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > The various "unlock" buttons in the control-center need to stay sensitive if
> > > the authorisation was cancelled (as opposed to auth failure), 
> > 
> > Interesting. Why shouldn't the unlock buttons stay sensitive even on auth
> > failure? I mean, it could be the user just inputs the wrong password... [1]
> 
> Huh. I got this wrong. It would try and show an error in some cases (see the
> "make default" case).

That makes sense, yeah - and what I suspected in comment 4. So it makes sense to add a way to figure if the auth dialog was dismissed (or not).

Still, current control center is busted in the way you describe.. e.g. the lock button should never be insensitive and spell 'Locked' if failing to obtain the authorization through authentication. Let me file a bug on bugzilla.gnome.org...
Comment 9 David Zeuthen (not reading bugmail) 2011-02-22 12:50:19 UTC
(In reply to comment #8)
> Still, current control center is busted in the way you describe.. e.g. the lock
> button should never be insensitive and spell 'Locked' if failing to obtain the
> authorization through authentication. Let me file a bug on
> bugzilla.gnome.org...

Filed here https://bugzilla.gnome.org/show_bug.cgi?id=642999
Comment 10 David Zeuthen (not reading bugmail) 2011-02-22 13:09:39 UTC
(In reply to comment #3)
> Another problem is how the Authentication Agent should convey to the Authority
> that the authentication dialog was actually dismissed by the user (I guess this
> is what you mean by "cancellation").
> 
> It should probably do this by returning the error
> org.freedesktop.PolicyKit1.Error.RequestDismissed in response to the
> BeginAuthentication() method call.
> 
> And then we need to figure out that this is conveyed back to the Mechanism. We
> should probably have a is_dismissed() method on the PolkitAuthorizationResult
> object.

We also need to figure out how to convey this in PolkitPermission - the best would probably to say that g_permission_acquire() should fail with G_IO_ERROR_CANCELLED in the event that the user dismisses an authentication dialog. Would be good to (retroactively) add that to the GLib docs.
Comment 11 David Zeuthen (not reading bugmail) 2011-02-22 13:52:52 UTC
OK, fixed in this commit:

 http://cgit.freedesktop.org/PolicyKit/commit/?id=986d7c293c6b35899a1e7bc6437f18775220dc47

Will follow up with a patch for gnome-shell's authentication agent shortly.

[davidz@x61 ~]$ pkexec bash
Error executing command as another user: Request dismissed
[davidz@x61 ~]$ echo $?
126
[davidz@x61 ~]$ pkexec bash
Error executing command as another user: Not authorized

This incident has been reported.
[davidz@x61 ~]$ echo $?
127
Comment 12 David Zeuthen (not reading bugmail) 2011-02-22 13:58:05 UTC
See https://bugzilla.gnome.org/show_bug.cgi?id=643007 for gnome-shell.

PolicyKit-gnome also needs a tiny fix.
Comment 13 David Zeuthen (not reading bugmail) 2011-02-22 16:35:02 UTC
(In reply to comment #12)
> PolicyKit-gnome also needs a tiny fix.

Fixed here: http://git.gnome.org/browse/PolicyKit-gnome/commit/?id=2511afae6b72fe3b4714d07ab6373c93c2923a5e


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.