Compatibility between D-Bus and kdbus

[Thiago Macieira]

On Tuesday 25 November 2014 11:08:19 Simon McVittie wrote:
> > I like this idea, with the proviso that Lennart pointed out: we need to
> > first include the metadata in the dbus1 stream messages so the
> > application can sort out the policy decisions like the kdbus
> > implementation would.
> 
> On Unix sockets I don't think we can get more metadata than we already
> have (uid, pid, LSM context), apart from possibly the primary GID.

That's not what I meant and I don't think that Lennart meant it either.

I meant that the D-Bus daemon should *always* include all the credentials it 
knows from the socket it received the message from whenever it forwards to 
another socket.

> We could certainly introduce message headers with the semantics of "this
> is the uid/pid/LSM context that opened the connection, and no other" to
> avoid services needing that round-trip: header fields
> INITIAL_UNIX_USER_ID (uint32) and perhaps INITIAL_PROCESS_ID (uint32)?

Yep, that's it.

> In principle we could also include the various LSMs' contexts, just like
> we could include them in GetConnectionCredentials, but someone who knows
> the relevant LSMs and can test and document them should do that, not me.

That too, right.

> > This might be a problem. Right now, QtDBus assumes that any match rule it
> > adds will be handled successfully. If the resource limit is low enough
> > that an application could hit it, we'll need to start handling the
> > failure case.
> Yes, and that's hard; GDBus doesn't handle this either. On the other
> hand, at least kdbus adds match rules via a synchronous ioctl rather
> than an async message.

Another point we have to take into account is that we'll have fewer rules now 
because the syntax is simpler. The client library will need to sort out false 
positives and drop unneeded messages. That said, the number can't be too 
small.

> > I'm not sure we need to keep the total ordering like you described. We can
> > probably relax it a bit to simply ensure causality.
> 
> My experience from implementing a D-Bus subset over link-local multicast
> on OLPC/Sugar, which explicitly didn't have better than causal ordering,
> is that application authors don't understand causal ordering.

Understand or not, did it make a difference?

> > Will systemd-kdbus provide [o.fd.DBus] on the bus so applications that
> > make
> > calls directly be able to continue working?
> 
> My understanding is "no, but client libraries may catch those messages
> and fake a reply".

I'd rather not intercept outgoing messages that aren't link-local. But if 
that's what's needed, I'll do. Except for:

> > org.freedesktop.DBus.ReloadConfig
> > org.freedesktop.DBus.StartServiceByName
> > org.freedesktop.DBus.UpdateActivationEnvironment
> 
> The equivalent is telling systemd to do equivalent things, although that
> isn't sufficient if there is going to be a non-systemd implementation of
> kdbus user-space

Those can't be emulated.

See more in the reply to Lennart's email.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358