Starting the kdbus discussions

[Simon McVittie]

On 27/12/13 00:04, Lennart Poettering wrote:
> http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-bus/PORTING-DBUS1

(As usual, doing my best to say "D-Bus" when I mean the abstract
protocol, and "dbus" or "dbus-daemon" when I mean the oddly-licensed
reference implementation of D-Bus.)

This discusses "simple types" and "trivial types". D-Bus has no such
things: as far as I can tell, your "trivial types" are our "fixed types"
(all the numbers including 'y' and 'b', plus the fd type 'h'), and your
"simple types" are our "basic types" (fixed types, plus the string-like
types 'g', 'o' and 's').

If your use of different terminology is accidental, please rename; if
it's deliberate, please define your terms (perhaps in terms of the ones
in D-Bus, or by copying text from the D-Bus Specification).

> Instead, you will only find PAYLOAD_OFF and PAYLOAD_MEMFD
> items. The former contain an offset and size into your memory mapped
> pool where you find the payload.

Relative to the beginning of the message, or relative to the beginning
of the pool?

> To allow clients to subscribe to specific subsets
> of the broadcast matches we employ bloom filters.

A behavioural difference that I think it's worth mentioning: in
dbus-daemon, the rule "broadcasts are available to anyone on the bus,
with no security restrictions" is a convention for the configurable
policy, but in kdbus, it's unavoidable technical fact. I don't think
that's bad - on the contrary, if someone told me they were actually
locking down readability of D-Bus broadcasts, my first reaction would be
"you get to keep both pieces" - but it's a difference.

> If the first argument of the message is a string, "arg0:" suffixed
> with the first argument.

When you say "string" here do you mean type signature 's', or do you
mean any string-like type? It'd be good if object paths were subject to
arg0 processing (at least for the slash-separation case), and I don't
see any particular reason not to extend at least arg0: to signatures.

(These instructions for how to form the bloom filter are part of the
kernel: transport for D-Bus, not part of the underlying kernel
functionality, right? The kernel doesn't care?)

> To install matches for broadcast messages, use the KDBUS_CMD_ADD_MATCH
> ioctl
[...]
> To match against other user messages add a KDBUS_ITEM_BLOOM item in
> the match (see above).

Does this mean that eavesdropping (receiving unicast messages intended
for a different recipient) is explicitly part of the kdbus API? This is
fine if it's what you want, but I would caution against making it easy
to do this by mistake - my recommendation would be to make sure that it
can only happen if "eavesdrop" (or some similar jargon word) actually
appears in your source code (see
<https://bugs.freedesktop.org/show_bug.cgi?id=37890>).

I would appreciate it if eavesdropping interacted with security policy
in a less insane way under kdbus than it does in dbus-daemon. Ideally:

* it should be possible for root to eavesdrop without weakening
  services' security - I think kdbus gets this "for free" by allowing
  arbitrary apps to send messages to any service, which can't be made
  any worse by turning on eavesdropping :-)

* unprivileged processes should not be able to eavesdrop on buses that
  are privilege boundaries (i.e. putting unencrypted secrets in unicast
  messages is currently OK to do, and IMO it should continue to be OK)

> The "memfd" concept is used for zero-copy data transfers (see
> above). memfds are file descriptors to memory chunks of arbitrary
> sizes.

If it works as well as it looks as though it should, then this seems
like a great piece of technology on its own, even without the rest of kdbus.

> With $UID replaced by the callers numer user ID, and $XDG_RUNTIME_DIR
> following the XDG basedir spec.

When substituting XDG_RUNTIME_DIR into a D-Bus address, it must be
escaped. (As an implementation detail, I think systemd only generates
values for XDG_RUNTIME_DIR where the escaped version equals the
unescaped version - but that isn't true in general, since it's a
user-controlled environment variable.)

> To additionally check against sender
> names, use the KDBUS_ITEM_ID (for unique id matches) and
> KDBUS_ITEM_NAME (for well-known name matches) item types.

Does this actually match how dbus match rules for well-known names work?
I believe dbus match rules interpret a well-known sender/destination as
meaning "must own this name or be in the queue for it", not "must own
this name" as I assume kdbus does - but please check that, I could be
mixing up match rule semantics with bus policy semantics. If I'm
remembering this correctly, then you might need to add a
KDBUS_ITEM_QUEUED_NAME in order to be able to implement AddMatch with
compatible semantics.

> - The org.freedesktop.DBus "driver" service is not special on
>   kdbus. It is a bus activated service like any other with its own
>   unique name.

My instinct is that this is going to break applications in obscure ways.
org.freedesktop.DBus is a strange mixture of a unique name and a
well-known name (syntactically it's a well-known name, but it's reported
to be its own owner like a unique name), because it's the thing that
defines/implements well-known names.

If o.fd.DBus exists as a real name at the kernel level, I'd be tempted
to implement it as a unique name with a known numeric value (either at
compile time or at runtime), and have a special case in the kernel
unique ID <-> D-Bus unique name mapping in libraries (at least, those
with existing API guarantees like GDBus) - something like "unique ID 1
maps to org.freedesktop.DBus, unique IDs 2+ map to :0.2, :0.3...", or
perhaps "the special unique ID you were told by the HELLO ioctl maps to
o.fd.DBus, and the rest map to :0.NNNN".

Of course, if o.fd.DBus is just something that's synthesized by client
libraries (like the special o.fd.DBus.Local pseudo-interface) in a kdbus
world, then it's easy to give it backwards-compatible semantics, so
please do :-)

> - NameAcquired/NameLost is gone entirely on kdbus backends if
>   libsystemd-bus is used.

This does make sense to me, though - it's easy for dbus and GDBus to
emulate it from the HELLO ioctl (for the unique name),
NameOwnerChanged(*, myself, *), and NameOwnerChanged(*, *, myself).
However, NameAcquired and NameLost do have the special property that
they are automatically received, with no explicit match rule needed.

To minimize breakage, please be careful to make sure that the kdbus port
of any existing library (i.e. dbus and GDBus, but not necessarily
libsystemd-bus) automatically subscribes to at least the subset of
NameOwnerChanged signals that will allow it to synthesize NameAcquired
and NameLost, and that it synthesizes these signals in the same order
that would be expected from dbus (I don't immediately know whether that
means "before NOC" or "after NOC" - the spec should say, but probably
doesn't).

    S