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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel