Bug 30653

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.

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

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.

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?

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

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

(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).

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

(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

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

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

See https://bugzilla.gnome.org/show_bug.cgi?id=643007 for gnome-shell.

PolicyKit-gnome also needs a tiny fix.

(In reply to comment #12)
> PolicyKit-gnome also needs a tiny fix.

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