|Summary:||Containers message filtering/policy (#101902): control over receiving Unix fds|
|Product:||dbus||Reporter:||Simon McVittie <smcv>|
|Component:||core||Assignee:||D-Bus Maintainers <dbus>|
|Status:||RESOLVED MOVED||QA Contact:||D-Bus Maintainers <dbus>|
|Priority:||medium||CC:||alexl, bugzilla, dbus, desrt, james|
|i915 platform:||i915 features:|
|Bug Depends on:||105656|
Description Simon McVittie 2018-03-21 12:42:56 UTC
+++ This bug was initially created as a clone of Bug #101902 +++ Allow rules (see Bug #101902) need to be able to opt-in to a container instance receiving Unix fds. To be designed ============== One of: * The rule's object path, bus name, interface must match the message * The bus name must match but the object path and interface must be non-specific * The object path, bus name, interface must be non-specific One of: * The flag works for both method calls and unicast signals and does not differentiate (this is a bit odd if filtering by path or interface is allowed, because they have different meanings in each direction) * The flag is split into RECEIVE_UNIX_FD_METHOD_CALLS and RECEIVE_UNIX_FD_SIGNALS * RECEIVE_UNIX_FDS is assumed to mean method calls because putting fds in signals is silly Out of scope ============ * Sending Unix fds * Receiving Unix fds in broadcast signals (which is ridiculous)
Comment 1 Simon McVittie 2018-06-01 19:24:09 UTC
We probably also need some way to say that if the container calls a method on some service, the reply can have fds in it? Maybe that's always allowed because it's up to that service how it behaves, but maybe it isn't because sending fds is a trust action?
Comment 2 GitLab Migration User 2018-10-12 21:34:15 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/202.