a message header flag for interactive authentication?

[Lennart Poettering]

Heya,

David Herrmann and I had the idea that it might make sense to introduce
a new message header flag in dbus messages for allowing interactive
authentication, and we thought it would be best to open the discussion
about this here!

So, what this is about: in both dbus1 and kdbus the built-in permission
management is strictly synchronous, and never interactive. Many of our
system-level daemons then add in support for PolicyKit on top of that,
for more fine-grained, and -- most importantly -- possibly interactive
authorization. Desktop environments like GNOME make heavy use of this
and have the polkit authorization agent built right into the desktop
shell.

Now, as we make steps towards app-sandboxing this kind of authnetication
scheme that we so far only applied to user code authenticating against
system services will probably be even more ubiquitiously used, for
authenticating unprviliged user apps against user services. Think of a
scheme where some app wants access to the user's address book...

Now, with this in mind, we will probably see a lot more services that
need to be made aware of authentication soonishly, because user-level
services might need to be covered as well now. 

So far, the usual scheme how user interaction was enabled for an
operation was to provide a bus method call with a special boolean
argument "user_interaction". If true, this would allow interactive
authentication, if false, this would only allow non-interactive
authentication. For an example how this looks, please see the docs for
systemd-timedated as one of the more trivial examples:

http://www.freedesktop.org/wiki/Software/systemd/timedated/

Now, for existing APIs adding interactive authentication suport would
mean that we'd have to duplicate all method calls: one version of the
method call to stay compatible with the current APIs, without the
boolean. And then a second one, with the boolean. This of course
certainly doesn't make things more readable and small...

We then started to think that it might make sense to add the boolean
right to the message header itself for this, inside the flag field. Given
how interlinked dbus and the need for inetractive authentication is,
this actually sounds like a good idea to me. Currently, the flags byte
only knows 2 flags (disable activation, and don't expect a reply), we'd
like to add a third one. This would relieve us from having to add the
boolean argument explicitly to all method calls.

We'd define the flag very generically, as
"allow-interactive-authentication" or so. It would default to off, and
would be a way for clients to tell services that they are OK if the
method call takes a long time due to the need for interactive
authentication, and that in the UI flow of the app such inetractivity is
OK. It would then be up to services to actually make use of the flag and
pass it on to polkit (or some other framework, we wouldn't hardcode that
in...)

We'd define the flag only for method call messages, nothing else.

Opinions?

if we can agree on this, I'd be willing to prep a patch for the spec.

Lennart

-- 
Lennart Poettering, Red Hat