[systemd-devel] [PATCH 0/4] [RFC v1] gdbus: Preliminary kdbus-support patches

[Lennart Poettering]

On Thu, 21.11.13 14:35, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> If you've forked dbus-daemon, definitely please discuss it with the
> people who understand that codebase.
> 
> My most important question whenever I look at D-Bus is: does this change
> break existing applications? Without having reviewed anything in detail,
> the major areas in kdbus that I'm concerned could break existing
> software are:

I can't talk about the Titen/Samsung version of dbus-daemon. But note
that for the classic dbus1 protocol next to zero will change, as the
compat daemon will enforce the old XML policy. Only clients talking
directly to kdbus will have to deal with the new policy logic.

As the policy is the last thing we will be working on inside of
kdbus/systemd there's nothing to discuss yet, as the new policy doesn't
exist at all yet. Heck, we haven't even booted a system with kdbus
replacing dbus-daemon yet. Yesterday I commited the last bits to convert
systemd entirely to libsystemd-bus so that we can start experimenting
with this, but it's too early to discuss policy changes.

> * retaining message-order guarantees, or at least, explicitly
>   documenting which ones have been relaxed and their impact on
>   applications (in dbus-1 there is one canonical order of messages,
>   and all processes see them in that order)

kdbus makes no changes there and guarantees global ordering.

> * having the subtler points of bus name ownership remain compatible
>   (the ability to queue for name ownership, etc.)

That'll be unchanged too in kdbus.

> * access control: it's fine if you want kdbus to have a less insane
>   security policy language than dbus-1; but if an existing libdbus,
>   QtDBus, GDBus etc. application was relying on the system dbus-daemon's
>   deny-by-default policy, and a library upgrade makes it connect to
>   kdbus instead of /run/dbus/system_bus_socket, then it isn't
>   acceptable for that application to be instantly security-buggy

Policy will change but only for clients connecting directly to kdbus,
those going via the old protocol won't have to.

> * edge cases involving large/many messages and who can DoS who, e.g.
>   see https://bugs.freedesktop.org/show_bug.cgi?id=33606
>   (I'm sure you've done better overall than dbus-1, but the question
>   is whether anything became worse as a result)
> 
> * portability: it's fine that kdbus is Linux-specific, but everything
>   that currently works on non-Linux (libdbus, GDBus etc.) should
>   continue to work at least as well as it does now

Yes, absolutely. In fact, libsystem-bus is fully compatible with dbus1,
too. In fact, that's how it currently is used to bring up a systemd
system still.

Lennart

-- 
Lennart Poettering, Red Hat