Proposed System Wide Change: Enable dbus-broker
https://fedoraproject.org/wiki/Changes/EnableDbusBroker


Owner(s):
  * David Herrmann <dh dot herrmann at gmail dot com>
  * Tom Gundersen <teg at jklm dot no>


Enable dbus-broker.service to use dbus-broker as system and session
message bus backend.



== Detailed description ==
The dbus-broker project is an implementation of a message bus as
defined by the D-Bus specification. Its aim is to provide high
performance and reliability, while keeping compatibility to the D-Bus
reference implementation. It is exclusively written for linux systems,
and makes use of many modern features provided by recent linux kernel
releases.
The main focus points of dbus-broker are reliability, scalability and
security. The dbus-broker project tries to improve on these points
over dbus-daemon, and thus provide a better alternative. And in-depth
analysis can be found in the initial
[https://dvdhrm.github.io/rethinking-the-dbus-message-bus/
announcement] of dbus-broker. An excerpt:
* [https://github.com/bus1/dbus-broker/wiki/Accounting Accounting]:
dbus-broker maintains per-user accounting, including inter-user
quotas. This guarantees that no single user can cause irregularly high
memory consumption in the daemon. Unlike dbus-broker, dbus-daemon
accounts memory in a multi-tier system, based on plain resource
counters on users, connections, and other resources. The multi-tier
system suffers from resource-chaining-exhaustion, where clients
effectively circumvent the accounting by creating multiple
connections/objects, which themselves grant them each a new set of
quotas. The [https://github.com/bus1/dbus-broker/wiki/Accounting
single-tier accounting] scheme of dbus-broker avoids this, while at
the same time adding inter-user quotas to prevent misuse even across
clients.
* [https://github.com/bus1/dbus-broker/wiki/Reliability Reliability]:
While D-Bus is used on reliable transports, dbus-daemon might still
silently drop messages and given circumstances. This is the only
possible solution dbus-daemon has, given several of its runtime
guarantees. The dbus-broker project changed the architecture of the
bus daemon to a degree, that it can provide many
[https://github.com/bus1/dbus-broker/wiki/Reliability guarantees],
including that no message will be silently, or unexpectedly, dropped.
* [https://github.com/bus1/dbus-broker/wiki/Scalability Scalability]:
The message bus broker is a crucial infrastructure on modern linux
system, which is a hot-path for almost all IPC going on. Hence, the
broker should perform fast and be scalable to its users. dbus-daemon
has several **global** data-structures that affect the overall
scalability of independent message transactions. dbus-broker does not
employ any global data-structures (unless required by the spec), as
such any message transaction is only affected by the data provided by
the involved peers. Moreover, even for spec-defined global behavior,
dbus-broker avoids global data-structures, unless clients actually
make use of these obscure features. In several other cases,
dbus-daemon scales O(n) time looking up message targets and related
data. dbus-broker runs all these in O(log(n)) time.
* Linux-specific: The dbus-broker project was explicitly designed for
linux system, making use of many linux-specific APIs and behavior.
This allows mitigation of several possible DoS attacks.


== Scope ==
* Proposal owners:
** Fix regressions.
** Enabledbus-broker.service in system and user-global context of
systemd (via systemd presets).
** Pull in dbus-broker package from dbus package.

* Other developers:
** Watch for regressions

* Release engineering:
[https://pagure.io/releng/issues/7262 #7262]

** List of deliverables:
N/A

* Policies and guidelines:
No changes needed.

* Trademark approval:
No changes needed.
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to