Starting the kdbus discussions

[Lennart Poettering]

On Mon, 06.01.14 11:18, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> The spec has only referred to fixed types since 2011, so I'd be happy to
> review a patch renaming that concept to "trivial types". That would make
> the type hierarchy into:
> 
> * basic
>   * trivial
>     * int16, uint32, handle, etc.
>   * string-like
>     * string
>     * object path
>     * signature
> * container
>   * array
>   * struct
>   * variant
>   * maybe    (GVariant extension)
> 
> I'd rather keep the name "basic type" rather than renaming it to "simple
> type", since that's been in the spec since at least 2005, and isn't
> misleading like "fixed" is.

This would be very near to how gvariant calls these types. GVariant
sometimes uses "base" types" instead of "basic" types however. Which
sounds mostly like a typo...

> > The kernel doesn't care about the bloom filter much. The identifier is
> > called "bloom", but other than that the kernel doesn't know much about
> > the contents of the match mask or the message filters
> 
> That makes sense. OK, so to the kdbus kernel module it's just opaque
> data, and it's the D-Bus kernel: transport that defines semantics. (I
> think it's worth distinguishing between the two.)

Correct. Defining these semantics are a primary job for the spec,
because otherwise kdbus userspace peers couldn't communicate even if the
kernel doesn't mind.

> >> Does this mean that eavesdropping (receiving unicast messages intended
> >> for a different recipient) is explicitly part of the kdbus API? This
> >> is
> > 
> > Note that the bloom stuff applies exclusively to broadcast
> > messages. Installing a bloom filter for unicast messages will yield no
> > results. This is because clients sending messages will not calculate and
> > attach the bloom filters for unicast messages, so there's nothing to
> > match again.
> 
> Sorry, I'm confused. The text I quoted says you use KDBUS_CMD_ADD_MATCH
> to match broadcasts, or KDBUS_ITEM_BLOOM to match "other user messages".
> What other messages?
> 
> Re-reading it: OK, I think I see what's going on there, it just wasn't
> immediately clear: you use KDBUS_CMD_ADD_MATCH to add a match rule for
> broadcasts, and one of the many possible fields in the kdbus equivalent
> of a dbus-1 "match rule" is KDBUS_ITEM_BLOOM, which is "match by any
> criteria that are too complicated or general to have their own
> KDBUS_ITEM_*".

Yupp, a sinlge match consists of multipme items. One item type can be
used to match against the routing meta-data (such as sender or
destination), and another item may contain a bloom filter. Only when all
these items match on a message it will be delivered to the subscribing
client. And bloom filters are the item types to use to match against
specific messages from userspace, that are sent as broadcast. 

> >>> 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?
> > 
> > What I wrote above was about NameOwnerChanged, which dbus-daemon only
> > generates when the real owner changes ownership. You will not get it for
> > queued names. The spec doesn't really clarify that, but I am pretty sure
> > that would be quite useless, if it sent them out just for queuing too...
> 
> Ah, right. Yes, you only see NameOwnerChanged when the "primary owner"
> changes.
> 
> My concern about the semantics of matching a queued sender/recipient in
> an AddMatch might still apply to your ADD_MATCH, but not to your
> NameOwnerChanged replacement.

Looking at the current dbus-daemon sources it only checks the primary
names of the sender, not any queued ones. It calls
connection_is_primary_owner() for the sender field in
match_rule_matches() in bus/signals.c.

So I figure what libsystemd-bus does here is pretty much identical to
what dbus-daemon does.

> > This is actually a good point you raise. For the bus proxy I have been
> > forth and back over this, i.e. when we forward a message from the proxy
> > whether we should override the sender for it, and make sure the unique
> > name is replaced with the well-known name in it. I have changed this
> > around and back a couple of times. Currently we leave the unique id in,
> > and everything i tested works fine, including gdbus for its own internal
> > messages to the driver.
> 
> In current D-Bus, messages that are forwarded through dbus-daemon are
> unconditionally rewritten to contain the *unique* name of the sender
> (e.g. :1.42), regardless of whether the original message had the unique
> name, a correct well-known name, a spoofed well-known name, or no sender
> field at all. For messages from the dbus-daemon itself - either signals
> or replies - we put "org.freedesktop.DBus" in the sender (this is one of
> the ways in which o.fd.DBus behaves like a unique name, even though it's
> syntactically a well-known name).
> 
> I would much prefer it if your proxy/bridge guaranteed to do the same:
> you're taking a performance hit to remarshal the message anyway, so you
> might as well make sure to be 100% compatible, and not have to worry
> about which implementations check this and under what circumstances.
> 
> I'm aware of several Telepathy applications that rely on method calls
> having an application's unique name as sender, and a dbus-glib security
> fix (CVE-2013-0292) that relies on NameOwnerChanged having o.fd.DBus as
> sender. I'm not sure about method responses, but to be honest it's
> better to do what dbus-daemon does and not have to worry about it.
> 
> The other context in which o.fd.DBus is special is when you ask the bus
> driver about it via method calls: for instance,
> GetNameOwner("org.freedesktop.DBus") == "org.freedesktop.DBus", just
> like a unique name.

OK, I have added this to the TODO list now. More specifically:

- We already override the sender for NameOwnerChanged to be the
  well-known name "org.freedesktop.DBus".

- Overriding the sender like this for native libsystemd-bus clients
  seems unnecessary, as clients need to be massively updated anyway if they
  use the new library.

- for clients of the bus proxy we should override the unique id sender
  for all method call responses from the driver to be the well-known name
  "org.freedesktop.DBus" to match behaviour of classic dbus-daemon.

- the bus driver should make sure that the owner of
  "org.freedesktop.DBus" is always "org.freedesktop.DBus" instead of the
  unique name. 

The latter two I added to the TODO list. Both together should have the
result that to dbus1 clients the unique id the driver actually has is
never visible.

Lennart

-- 
Lennart Poettering, Red Hat