[PATCH] dbus-spec: introduce new PERMIT_INTERACTIVE_AUTHENTICATION

[Lennart Poettering]

On Thu, 04.09.14 08:22, Ted Gould (ted at gould.cx) wrote:

> On Wed, 2014-09-03 at 20:26 +0200, Lennart Poettering wrote:
> 
> > +                <entry><literal>PERMIT_INTERACTIVE_AUTHENTICATION</literal></entry>
> 
> 
> I think that the flag needs to be inverted. If we look today, services
> are expecting that clients will allow interactive authentication and the
> flag is set to zero. So a service would either have to break existing
> clients or somehow determine whether they knew about the flag to make a
> good choice. If a '1' there was made to be requesting a short reply the
> current assumption about zero today would be adequate no mater if the
> caller was aware of the new flag or not.

I strongly disagree on this one.

So far, the majority of bus APIs hooked up to policykit always exposed
an explicit boolean in the method call signatures to permit ineractive
authentication. And APIs that didn't do that would not use polkit
interactivity. If we add a header flag, then it should allow us to
keep the simple method calls without the explicit boolean argument,
but open them up for interactivity. This means, the flag should be off
by default, and if people want interactivity, they need to turn it on.

The default should eb no inetractive, and short timeouts. If you want
to allow interactivity, set the flag and bump up your timeout.

Also, this is kinda an UI question too: in many cases it is not
desirable to allow interrupting the UI with interactivity, so we
should suddenly do that where we previously didn't unless the
developer turns it on explicitly.

> Also, I think we should add at the same time a standard error for "you
> wanted quick, but I need interactive." (though it seems errors are only
> described in the spec in relation to specific messages, so I'm not sure
> where to put it)

I agree with this one, this makes a lot of sense. Currently the spec
is not very good ad defining errors, but we should certainly add one
for this case.

I'll update my patch and repost it.

Lennart

-- 
Lennart Poettering, Red Hat