Monitor example doesn't connect when dbus-monitor does

[Ppjet6]

The monitor example and dbus-monitor seem to have different behaviour. I have been trying to monitor the system bus as a user. dbus-monitor --system works using eavesdropping, the monitor example gets an error back. I am new at dbus so take all this with a grain of salt.

Using Archlinux, dbus 1.14.0-1, systemd 251.2-1, linux 5.18.8-arch1-1.

Steps to reproduce

• cat /etc/polkit-1/rules.d/50-monitor.rules.

polkit.addRule(function(action, subject) {
  if ((action.id == "org.freedesktop.DBus" ||
       action.id == "org.freedesktop.DBus.Monitoring") &&
      subject.isInGroup("wheel")) {
    return polkit.Result.YES;
  }
});

• dbus-monitor --system
• cargo run --example=monitor with Connection.new_system instead of Connection.new_session

Expected behaviour

Both behave the same way, they start listening (using BecomeMonitor).

Actual behaviour

dbus-monitor fallbacks on eavesdropping and starts listening:

dbus-monitor: unable to enable new-style monitoring: org.freedesktop.DBus.Error.AccessDenied: "Rejected send message, 1 matched rules; type="method_call", sender=":1.175" (uid=1000 pid=12496 comm="dbus-monitor --s
ystem") interface="org.freedesktop.DBus.Monitoring" member="BecomeMonitor" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)". Falling back to eavesdropping.
signal time=1657056969.025845 sender=org.freedesktop.DBus -> destination=:1.175 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.175"
[..]

The monitor example fails with:

     Running `target/debug/examples/monitor`
thread 'main' panicked at 'add_match failed: D-Bus error: rejected attempt to call AddMatch by connection :1.180 (uid=1000 pid=13118 comm="target/debug/examples/monitor") with uid 1000 (org.freedesktop.DBus.Error.AccessDenied)', examples/monitor.rs:35:12
stack backtrace:
   0: rust_begin_unwind
             at /rustc/ddcbba036aee08f0709f98a92a342a278eae5c05/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/ddcbba036aee08f0709f98a92a342a278eae5c05/library/core/src/panicking.rs:142:14
   2: core::result::unwrap_failed
             at /rustc/ddcbba036aee08f0709f98a92a342a278eae5c05/library/core/src/result.rs:1805:5
   3: core::result::Result<T,E>::expect
             at /rustc/ddcbba036aee08f0709f98a92a342a278eae5c05/library/core/src/result.rs:1055:23
   4: monitor::main
             at ./examples/monitor.rs:32:9
   5: core::ops::function::FnOnce::call_once
             at /rustc/ddcbba036aee08f0709f98a92a342a278eae5c05/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

My polkit rule may be granting lots of rights. I don't think I need org.freedesktop.DBus. Happy to remove it when I get stuff to work otherwise.
They both work as expected as root, I guess that's no surprise. dbus-monitor does fallback to eavesdropping so I guess I might be doing something wrong anyway?

[diwic]

Hi!

Looking at the code of dbus-monitor.c it seems to have another fallback - if the eavesdropping also fails, it tries to add a match with an empty match string.

Could you make the same adjustments to monitor.rs and see if that helps your use case, and if so, submit a PR?

[Ppjet6]

I submitted #392, and it manages to connect. My goal wasn't exactly to copy dbus-monitor though but rather to solve my issue and use BecomeMonitor, as I understand it's now the recommended way. Maybe you have an idea where I can get help with this?

[diwic]

My goal wasn't exactly to copy dbus-monitor though but rather to solve my issue and use BecomeMonitor, as I understand it's now the recommended way. Maybe you have an idea where I can get help with this?

I'm not running Arch but maybe /var/log/syslog can tell why the BecomeMonitor request was denied?

[diwic]

Closing due to inactivity. Please reopen in case you (or anyone else) is still interested. Thanks!