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

[Karol Lewandowski]

On 11/21/2013 03:35 PM, Simon McVittie wrote:
> On 21/11/13 11:33, Karol Lewandowski wrote:
>> [ Cced systemd-devel@ and dev at tizen mailing lists in case someone
>>   there would be interested too. ]
> 
> The maintainers of the D-Bus specification and reference implementation
> can be contacted via dbus at lists.freedesktop.org and the freedesktop.org
> Bugzilla.
> 
> If it is your intention to redefine what "D-Bus" effectively means,

It's not.

> please discuss it with the relevant community, and be prepared to
> justify design decisions (or change them, if it turns out something has
> been overlooked).
> 
> Sorry, I don't have time to find and review the various kdbus
> branches/projects right now, but perhaps another dbus committer (Colin?
> Thiago? Lennart?) does.

Truth is that gio guys already merged tizen's glib-kdbus modifications
into their own devel branch without us even knowing, not to mention
proposing it.  This is one of the reasons I felt it's needed to
clean it up, and send it as RFC if they find it that valuable.


>>    Currently we use modified[3] dbus-daemon to for that
>>    purpose.
> 
> If you've forked dbus-daemon, definitely please discuss it with the
> people who understand that codebase.

I believe that in long term systemd will provide org.freedesktop.DBus
service (both me and Lennart wrote that Daniel Mack already started
that work).  This is what dbus-daemon modifications were for.

IOW, with systemd-provided org.freedesktop.DBus service/bridge
dbus-daemon modifications won't be needed.


> 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:
> 
> * 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)
> 
> * having the subtler points of bus name ownership remain compatible
>   (the ability to queue for name ownership, etc.)
> 
> * 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
> 
> * 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

I believe that all of these are valid concerns, and will have to
be addressed in the end.

However, what we are focusing on here, with this patchset, is
far more limited in scope - checking if our approach to glib
extensions/changes is valid at all.

Thanks for your comments!

Cheers,
Karol