[ANNOUNCE] D-Bus Broker Project

[David Herrmann]

Hi

On Mon, Sep 4, 2017 at 7:18 PM, Thiago Macieira <thiago at kde.org> wrote:
> On Monday, 4 September 2017 13:18:46 -03 David Herrmann wrote:
>> A directed signal (or in fact *any* signal) is considered solicited if
>> a Match-Entry of the receiver matches the message. Unlike broadcasts,
>> unsolicited *unicast* signals are still delivered (mostly for
>> backwards compatibility).
[...]
> That means those signals are hardly ever subscribed to. Most importantly, the
> first of such signals is often sent before the receiver even has the
> information required to subscribe to it in the first place. According to your
> description, those signals would be considered unsolicited, even though the
> higher level API would consider them solicited (due to the method call that
> caused it to be emitted).
>
> How would this affect your solution? Suppose a malicious program makes a call
> which results in a system daemon sending a series of directed signals back at
> the caller. Those should be accounted to the caller, not the system daemon.

In dbus-daemon(1), those messages are accounted on the sender of the
signal, so are they in dbus-broker(1). Those messages have never been
considered solicited. Hence, there has always been the issue of
malicious peers triggering those messages without dispatching them.

In my opinion, those APIs should take object-paths as input, to
describe the new subscriber. So image you want to subscribe to
device-events, you would call:

    SubscribeDevice(o device, o subscriber, ...)

The subscriber object-path would then be used in the *directed*
signals, to allow the caller to install matches on them before
actually subscribing. This has many more benefits, btw. For instance,
you can cancel your subscription before the subscribe call returns
(because you already know the object-path of the subscription).

I know, this is not how those APIs were designed in the past, and we
are still supporting all this. But if you want directed signals to be
solicited, you need to install a match. dbus-daemon(1) has no policy
on those, so we cannot just mark them solicited.

Thanks
David