[PATCH] dbus-spec: introduce new PERMIT_INTERACTIVE_AUTHENTICATION

[Lennart Poettering]

On Wed, 03.09.14 15:40, Thiago Macieira (thiago at kde.org) wrote:

> On Wednesday 03 September 2014 15:16:46 Marcel Holtmann wrote:
> > Hi Thiago,
> > 
> > > How about removing the part about authentication and privileges, simply
> > > make the flag indicate that the caller is ok with a lengthy operation
> > > from the callee?
> > 
> > if the caller is okay with a lengthy operation it can just set the timeout
> > to whatever it feels is appropriate.
> 
> It can and it should do that, as the text that Lennart proposed also says. But 
> how does the callee know that the caller can wait for a long time?

Well, it's the callers fault if he asks for interactive auth, but then
doesn't wait to reap the benefits of this...

> The reason I'm asking to make this not specific to authentication is that I 
> don't want to add another PERMIT_INTERACTIVE_xxx flag later just because it's 
> not related to authentication (PERMIT_INTERACTIVE_COOKIE_HANDLING? 
> PERMIT_INTERACTIVE_SAVE_DIALOG?)

Well, we have an immediate need now for the auth interactive flag, and
auth is something that happens for a large number of methods as simple
part of the operation. That's why dbus has policy already built in,
and why polkit exists, to make it easy to do auth for methods offered
via the bus. 

This is different for something like your suggested "save-dialog"
flag, because that is a very specific thing, showing save dialogs via
bus methods calls is not a common property of all method calls, it's a
very exceptional one.

Also see the example I gave in the other mail, that it matters why
client need to be able to know that it is interactive *auth* that they
disable, nothing else.

I mean, if such a entirely generic interactivity flag makes sense one
day, we can add that too, but for now, let's focus on what we really
need right now, where we have existing usecases.

We still currently have 6 unused bits, and we can certainly extend the
field easy by adding in a new header field extension one day, we
shouldn't be too afraif of adding new bits from time to time if strong
usecases arise. 

I simply think the auth one is a strong usecase, now, and there's
reason to make it specific enough to declare that it is about auth,
and nothing else. And there might be other usecases that are worth
covering, but that's nothing we need now, and I think the case is much
weaker...

Lennart

-- 
Lennart Poettering, Red Hat