| 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> |
| Severity: | enhancement | ||
| Priority: | lowest | CC: | alexl, dbus, desrt, smcv |
| Version: | git master | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 101354 | ||
| Bug Blocks: | |||
|
Description
Simon McVittie
2017-10-26 15:54:11 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. 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. (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. -- 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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.