Hello, Just a quick question...dbus was patched to support SE Linux. I see no mention of SE Linux support below. Does it replicate the same SE Linux support? Thanks, -Steve On Tue, 13 Mar 2018 17:32:20 +0100 Jan Kurik <jkurik@xxxxxxxxxx> wrote: > = Proposed System Wide Change: Make dbus-broker the default DBus > implementation = > https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementation > > > 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 announcement of dbus-broker. An > excerpt: > > * 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 single-tier accounting scheme of dbus-broker avoids this, > while at the same time adding inter-user quotas to prevent misuse even > across clients. > > * 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 guarantees, > including that no message will be silently, or unexpectedly, dropped. > > * 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. > ** Enable dbus-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: #7262 https://pagure.io/releng/issues/7262 > > * List of deliverables: > N/A > > * Policies and guidelines: > No changes needed. > > * Trademark approval: > No changes needed. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
