a message header flag for interactive authentication?

Lennart Poettering mzqohf at 0pointer.de
Tue Aug 26 12:40:18 PDT 2014


On Tue, 26.08.14 12:32, Thiago Macieira (thiago at kde.org) wrote:

> 
> On Tuesday 26 August 2014 21:22:24 Lennart Poettering wrote:
> > Well the way I see it is that pretty much everybody who uses dbus needs
> > an authentication framework, that fills in where dbus built-in policy is
> > not enough. Any real-life application needs something like this, dbus is
> > simply not that useful without it. Pretty much all our system daemons in
> > the general stack that use dbus actually hook into polkit, due to that...
> 
> While I agree that system services do need authentication, polkit is not the 
> only solution. Other frameworks may need other types of metadata. Please see 
> the Cynara framework being developed for Tizen.

Well, I am aware that polkit is not the only solution, that's why I
didn't propose calling this "polkit-allow-interactive" but generically
just "allow-interactive-auth"...

I mean, for a client it really doesn't matter what is used in the
backend. It should simply declare that it is willing to wait for longer,
and is OK with an auth box to pop-up. Whether the server-side then call
into polkit, into "cynara" or something else, is irrelevant for it...

Having this generically in the msg hdr, is good for everybody, because
it doesn't hardcode things to any specific backend, it is merely a hint
that backends can make use of, but don't have to...

> > Hence, given that this is how it is, I am pretty sure this is not just
> > arbitrary use metadata, but very close to how dbus is used in almost all
> > of the cases, and hence deserves the header flag...
> 
> It deserves some kind of metadata. But I think restricting it to one boolean 
> is shortsighted.

well, every flag we add to the msg flags param should be vetted
here... Quite frankly i don#t really see any need for any other flags
for now, so I am not discussing that...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the dbus mailing list