|Summary:||Containers (#100344): Let monitors match messages to/from a container|
|Product:||dbus||Reporter:||Simon McVittie <smcv>|
|Component:||core||Assignee:||Simon McVittie <smcv>|
|Status:||RESOLVED MOVED||QA Contact:||D-Bus Maintainers <dbus>|
|Priority:||lowest||CC:||alexl, dbus, desrt, smcv|
|i915 platform:||i915 features:|
|Bug Depends on:||101354|
Description Simon McVittie 2017-10-26 15:54:11 UTC
Flatpak has "flatpak run --log-system-bus --log-session-bus", implemented by passing arguments to the flatpak-dbus-proxy. To get rid of the flatpak-dbus-proxy, we should achieve feature parity with it; so there should be some arguments that Flatpak can pass to dbus-monitor that will make it log traffic to/from a container. dbus-monitor uses the Monitoring interface, which uses match rules, so we will need a match rule with container=/org/freedesktop/DBus/Containers1/c47, or a pair of rules with sender_container=/org/freedesktop/DBus/Containers1/c47 and destination_container=/org/freedesktop/DBus/Containers1/c47.
Comment 1 Simon McVittie 2017-10-26 16:00:38 UTC
What we need: * Add a match rule keyword (e.g. container or sender_container) matching messages that were sent by a particular container instance. This is easy. * Add a match rule keyword (e.g. container or destination_container) matching unicast messages directed to a particular container instance. This is easy. * Add a match rule keyword (e.g. container or destination_container) matching broadcast messages that will be received by a particular container instance. This is a lot more subtle - we currently run the matchmaker (to work out who is going to get the message) after we capture it for monitors, but we can't know whether a broadcast is going to be received by a container until we've run the matchmaker. Another subtlety is that the new keyword probably cannot work in AddMatch(), because if it did, that would mean the matchmaker couldn't decide whether to send a broadcast to a destination until after we had finished running the matchmaker... If the container instance is somehow monitoring or eavesdropping (which would require us to have relaxed the security policy for container instances, Bug #103458), then I think it would be OK if the new keyword didn't match the messages that the container instance gets as a result (monitoring would be another circular dependency, while eavesdropping is solvable because it's equivalent to receiving a broadcast). Containers that are monitoring traffic are so excessively privileged anyway that the need to debug what they are and aren't receiving should be extremely small :-) Perhaps it would be an acceptable simplification if the new keyword only works on its own, and not when combined with others in a single match rule? That way, we could capture messages for normal monitoring as a first pass before running the matchmaker, and capture messages for container monitoring as a second pass after running the matchmaker.
Comment 2 Alexander Larsson 2017-10-27 13:04:44 UTC
I'm not sure this is 100% required. This is mainly used for debugging why an app fails (due to dbus filtering). If we use the real dbus-daemon, then one can just run dbus-monitor on the host to see what goes on.
Comment 3 Simon McVittie 2017-10-30 11:51:26 UTC
(In reply to Alexander Larsson from comment #2) > I'm not sure this is 100% required. This is mainly used for debugging why an > app fails (due to dbus filtering). If we use the real dbus-daemon, then one > can just run dbus-monitor on the host to see what goes on. OK, that's good to know. I'll leave the feature request open, but take it off the critical path in planning whether/when I have time to implement #100344.
Comment 4 GitLab Migration User 2018-10-12 21:32:09 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/190.