a message header flag for interactive authentication?

[Lennart Poettering]

On Tue, 26.08.14 11:41, 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 am not convinced really that we should make this that complicated. I
mean, maybe one day, when the flags param is fully used, we can add an
extended flags field, to add more bits...

Also, and more importantly, to me this really isn't an arbitrary user
extension (for which adding a generic dictionary to the header might
make sense), but so close to how we use dbus, that it deserves a flag in
the header...

Lennart

-- 
Lennart Poettering, Red Hat