[systemd-devel] sd-bus connections & authentication timeout

[Simon McVittie]

On Mon, 20 Mar 2017 at 19:40:04 +0100, Stanislav Angelovič wrote:
> Regarding polling, I understand, but I fear this way we could get race
> condition on the connection instance, since we'd have a thread doing the
> polling and processing in a loop on the connection, and some other thread (say
> handling the UI, or an external system event, or incoming DBus call from
> another connection or whatever else) issuing a DBus call on the same
> connection.

Don't do this. The sd-bus connection is not designed to be safe to
access from multiple threads.

If you need thread-safe D-Bus, then you will need a design where one thread
"dispatches" the D-Bus connection (with sd-event or the GLib
main loop or whatever abstraction around epoll/poll/select you prefer),
and all other threads submit requests to it and get events back from it.
This is essentially what GLib's GDBus does - all the public APIs just
submit requests to a worker thread that is not directly accessible by
user code.

libdbus (the reference implementation of D-Bus) did try to support the
situation you are concerned about, but doing that turns out to be basically
unmaintainable; we've fixed the worst issues, but it has never been very
reliable, and we strongly recommend not doing it. For best results, choose
either always-threaded (GDBus' design) or never-threaded (sd-bus' design,
and also the recommended pattern for libdbus for the last few years)
and stick to it.

> This involves asynchronous programming paradigm for quite a simple
> thing, IMHO.

D-Bus is fundamentally an asynchronous message-passing system, in the
same sorts of ways that X11, Wayland and most network protocols are.
If asynchronous message passing is not acceptable to you, then D-Bus is
probably not going to be the right solution to your requirements.

If you stop reading from your D-Bus socket, the dbus-daemon will
eventually have to disconnect you, because it cannot distinguish
between that and a denial of service attack. The timeout that you
encountered is precisely there to stop malicious processes from carrying
out a denial of service attack on the system dbus-daemon instance
by tying up all of its file descriptors with unauthenticated connections,
and there are similar limits to stop a malicious process from carrying
out a DoS attack on the system dbus-daemon instance by making it
consume unbounded amounts of memory.

In general we put these arbitrary limits in for good reasons, not
just to make your life difficult :-) In this case the relevant
security vulnerability was CVE-2014-3639.

    S