D-Bus optimizations

[Simon McVittie]

On 01/03/12 12:49, Thiago Macieira wrote:
> On quinta-feira, 1 de março de 2012 07.36.53, Colin Walters wrote:
>> On Tue, 2012-02-28 at 13:56 +0100, Thiago Macieira wrote:
>>> This applies to malformed messages, but does not apply to well-formed but
>>> spoofed messages. The checking of the credentials needs to be done by a
>>> trusted source.

I believe the plan is that senders supporting multicast will be required
to put their own unique name in the message headers
(as for <https://bugs.freedesktop.org/show_bug.cgi?id=38289>, but
required instead of optional), and the dbus-daemon will apply Berkeley
packet filters to the socket, to filter out spoofed messages at the
kernel level.

That'd need libdbus/GDBus changes for the senders... but so does
supporting multicast at all, so we can have one be a prerequisite for
the other.

> We'd still want some checking to make sure we don't have a broken application 
> sending out messages for a name it tried to register and failed, or registered 
> and lost.

At the moment the sender is effectively always the unique name, and
never an owned well-known name, so this hopefully shouldn't arise.

At the moment, libdbus senders never write out a sender header (unless
application code does it - but there's no reason to do so while on a
bus, because it will never achieve anything), and the dbus-daemon
unconditionally sets one (silently dropping anything the client put
there). I'm not sure whether GDBus writes out a sender header or not; if
it does, dbus-daemon unconditionally overwrites it anyway.

My plan for #38289 was that DBusConnection should grow a sender_name
field and set_sender_name() method, dbus_bus_* would change to using the
same internal field as the "sender name" for the unique name, and at the
last moment before sending an outgoing message, we'd set the sender name
to conn->sender_name, unless that was NULL.

This would immediately help non-multicast dbus-daemons too, since they
could validate the sender name, and if valid, not overwrite it (which
saves a lot of hairy realignment code). In the longer term I want the
DBusMessage header to be sent by scatter-gather I/O, so new fields are
just added to a list (an array keyed by header ID, probably) and nothing
ever needs to be inserted into a message, only appended (for the body,
which is already append-only), so there is never any realignment.

If you don't call either dbus_bus_set_unique_name() (or something that
sets it, like dbus_bus_register()) or dbus_connection_set_sender_name(),
then conn->sender_name would remain NULL, and the DBusConnection would
still leave the message untouched - "dbus-daemon mode", for situations
where you need to pass on a message with its sender intact.

    S