a message header flag for interactive authentication?

Lennart Poettering mzqohf at 0pointer.de
Thu Aug 28 06:34:47 PDT 2014


On Thu, 28.08.14 11:24, Alban Crequy (alban.crequy at collabora.co.uk) wrote:

> 
> On Wed, 27 Aug 2014 08:03:16 -0700
> Thiago Macieira <thiago at kde.org> wrote:
> 
> > On Wednesday 27 August 2014 10:41:02 Alban Crequy wrote:
> > > 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.
> > 
> > So what do you recommend instead?
> 
> I have no real objections in adding a bit in the existing flag field,
> along NO_REPLY_EXPECTED and NO_AUTO_START.
> 
> I would like a couple more examples than just the addressbook though.
> And if the new bit is only for D-Bus method calls, what if the
> addressbook emits D-Bus signals to signal some changes in a contact
> details? In this case, I'm not sure the authentication scheme would work
> without changing the D-Bus API.

well, on the system-bus side we have tons of real-life, existing
examples, where this would be useful: timedated, localed, hostnamed,
logind, machined, systemd, udisks, upower, nm, pkgkit, rtkit, ... all of
the things that make up our core operating system...

And on the user-bus side, if we do sandboxed apps, i could think of
address book access, access to the keyring, to calendar, online
accounts, maybe access to certain configuration things, like display
management,

And there's stuff where it isn't clear whether it should be on the user
or system bus, such as location stuff...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the dbus mailing list