a message header flag for interactive authentication?

[Alban Crequy]

On Tue, 26 Aug 2014 11:41:48 -0700
Thiago Macieira <thiago at kde.org> wrote:

> On Tuesday 26 August 2014 18:22:41 Lennart Poettering wrote:
> > 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?
> 
> I like this, but I suggest we extend to a more generic mechanism. The
> message header contains a "a(yv)" structure. So we should simply add
> a header field like "USER_METADATA" (value 10) and in the variant
> store the user's data.
> 
> The most generic mechanism is that the variant contain a "(sv)"
> struct, so the user can add any value to a string key type. If we
> want to make this simpler, we could restrict it to string-string or
> int-int pairs.
> 
> Metadata CAN be ignored by the callee and the callee MUST NOT rely on
> it being there. If the callee requires it, it should be part of the
> parameters, not metadata.

I would prefer if the headers are not too difficult to parse if not
necessary. At the moment, the headers don't have any "body offset" field
to know where the body of the message starts. So any implementation
would need to parse the header completely, even if it is not interested
in everything. Adding a "(sv)" means there could be more variants to
parse recursively.

The header signature is "yyyyuua(yv)" so it already has a variant but
the possible nested types are limited and it does not have
recursive variants.

The possible use cases I see which would benefit from a easy & fast to
parse headers are:

- usual client libraries (libdbus, GDBus): avoid losing time in parsing
  complicated variants?
- if AppArmor gets support for kdbus and decides to parse messages in
  the kernel in order to apply policies on interface, member, etc.
  (since interface, member etc. are not in the kdbus headers)
- AF_BUS (as an example) parsed the header to find the body offset so
  it could route messages for match rules containing a arg0 criteria.
  But it was not interested in all header fields, so it quickly skip
  them.

Cheers,
Alban