BecomeMonitor with destination matching returns too many unrelated messages

[hexchain]

I'm trying to monitor a specific service, but dbus-broker gives me lots of other unrelated messages:

% dbus-monitor destination=org.kde.plasma.gmenu_dbusmenu_proxy | grep 'method call'
method call time=1590615112.124345 sender=:1.1061 -> destination=org.freedesktop.DBus serial=1621 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetConnectionUnixProcessID
method call time=1590615112.746956 sender=:1.457 -> destination=org.kde.StatusNotifierItem-1808-1 serial=58238 path=/StatusNotifierItem; interface=org.freedesktop.DBus.Properties; member=GetAll
method call time=1590615112.849471 sender=:1.1113 -> destination=:1.55 serial=71 path=/org/freedesktop/portal/inputcontext/1220; interface=org.fcitx.Fcitx.InputContext1; member=FocusIn
method call time=1590615112.849870 sender=:1.1113 -> destination=:1.55 serial=72 path=/org/freedesktop/portal/inputcontext/1220; interface=org.fcitx.Fcitx.InputContext1; member=FocusOut
method call time=1590615112.849917 sender=:1.1113 -> destination=:1.55 serial=73 path=/org/freedesktop/portal/inputcontext/1220; interface=org.fcitx.Fcitx.InputContext1; member=FocusIn
method call time=1590615112.876205 sender=:1.457 -> destination=:1.1114 serial=58239 path=/MenuBar/1; interface=com.canonical.dbusmenu; member=AboutToShow
method call time=1590615112.876272 sender=:1.457 -> destination=:1.1114 serial=58240 path=/MenuBar/1; interface=com.canonical.dbusmenu; member=Event
method call time=1590615112.879642 sender=:1.457 -> destination=:1.1114 serial=58241 path=/MenuBar/1; interface=com.canonical.dbusmenu; member=AboutToShow
method call time=1590615112.881539 sender=:1.457 -> destination=:1.1114 serial=58242 path=/MenuBar/1; interface=com.canonical.dbusmenu; member=Event
method call time=1590615112.881573 sender=:1.457 -> destination=:1.1114 serial=58243 path=/MenuBar/1; interface=com.canonical.dbusmenu; member=AboutToShow
method call time=1590615112.881578 sender=:1.457 -> destination=:1.1114 serial=58244 path=/MenuBar/1; interface=com.canonical.dbusmenu; member=Event
method call time=1590615112.881584 sender=:1.457 -> destination=:1.1114 serial=58245 path=/MenuBar/1; interface=com.canonical.dbusmenu; member=AboutToShow
...

All of these have nothing to do with org.kde.plasma.gmenu_dbusmenu_proxy. They are neither coming from nor heading to the process holding that service name.

From the wiki, I am aware that "we err on the side of delivering unexpected messages, rather than dropping expected ones" when destination matching is in use, but I'm not expecting such a low signal-to-noise ratio.

EDIT: Okay, apparently I somehow missed the previous sentence: "we treat any match specifying a destination filter as if the destination filter had not been there", so I guess this is expected.

[hexchain]

Well, there's still a problem:

I'm trying to use busctl monitor xxxx, which sets up a sender= and a destination= match on the same service name: https://github.com/systemd/systemd/blob/master/src/busctl/busctl.c#L1260-L1282. But when I tried to monitor some nonexistent service name, it returned every message on the bus as if no filter was there. The same behavior can be seen with dbus-monitor sender=x.y.z destination=x.y.z.

Could this be a bug in dbus-broker?

[dvdhrm]

It installs 2 matches, one for sender= and one for destination=. Installing multiple matches causes them to be additive, not selective. Hence, if either matches, you get the message. Installing a destination= rule is thus a catch-all rule, and you get all messages.

I know, this is quite unfortunate. However, I am unaware of a solution for this. The dbus-specification defines this in a way that just either causes spurious message drops, or you just don't filter (as we do).

[dvdhrm]

I will close this, as this is the expected and documented behavior. Given the current specification, I am unaware of a solution for this unfortunate feature disparity. If anyone has more input on this, please let us know!

[pemensik]

Can you please point me to mentioned documentation? I have tried to find this in both busctl monitor man page or help and dbus-monitor man page, but neither mentions this issue. It seems to me expected. Issue #367 can be seen as duplicate, but also proof this is not seen as fixed.

[dvdhrm]

Can you please point me to mentioned documentation? I have tried to find this in both busctl monitor man page or help and dbus-monitor man page, but neither mentions this issue. It seems to me expected. Issue #367 can be seen as duplicate, but also proof this is not seen as fixed.

This behavior is specific to dbus-broker and documented as part of its deviations to the reference implementation: https://github.com/bus1/dbus-broker/wiki/Deviations

[pemensik]

I am afraid documenting it at that location is well hidden from mere mortal wondering, why the filtering does not work. It has no indication in manual pages of tools using it. I tend to think broker should just refuse that filter and force those tools use not ignored destination filter, but omit it from the filter.

What is the reason for accepting something being ignored? Are there specific applications, which set destination filter but would be difficult to modify to omit it? At least for those monitor tools that filter were given explicitly by the user, so ignoring it silently is not user intuitive. Especially for busctl, which does not have other filters possible.

If it could emit just warning message as the first received message, it might work better. I don't understand DBus protocol enough to know possible fixes. I understand documenting it on monitor tools is tricky, because they can be used on previous dbus-daemon, where this limitation does not apply. So ideally it should be emitted from dbus-broker runtime.

In current form it means dbus-broker-33-1.fc38.x86_64 does not contain this information anywhere in the binary package. Hasn't change in rawhide dbus-broker-36-2.fc41.x86_64.