Some D-Bus services, most notably Telepathy, rely on being able to own dynamically formed bus names, sharing a common prefix. This does not work in bus configurations where arbitrary name ownership is prohibited. <allow own="..."/> rules only work with either "*" or exact string matches. Quoth Simon McVittie in bug #46882 comment #1: > There's nothing to stop someone implementing > > <allow own_prefix="org.freedesktop.Telepathy.Connection.gabble"/> > > as something the policy language can do. With my D-Bus maintainer hat on, I > think that'd be a better way to represent this than supporting shell-style glob > patterns.
Branch own_prefix implemented, see the URL.
I take it these have the same policy as arg0prefix in match rules, with the same semantics? I feel as though own_prefix ought to be documented a bit better (and yes, I know the man page doesn't really document own either). It seems its semantics are: <allow own_prefix="a.b"/> allows you to own the name "a.b" or any name whose first dot-separated elements are "a.b": in particular, you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c". This is useful when services like Telepathy and ReserveDevice define a meaning for subtrees of well-known names, such as org.freedesktop.Telepathy.ConnectionManager.(anything) and org.freedesktop.ReserveDevice1.(anything). The implementation looks fine. I'm going to ask on the D-Bus mailing list and check that nobody wants to veto this.
(In reply to comment #1) > Branch own_prefix implemented, see the URL. This also lacks automated tests. I'd like to see a test where this rule makes a difference. The most realistic test would be to <allow own_prefix="com.example.Subtree"/> as an exception to the general deny-all policy in test/name-test/tmp-session-like-system.conf, and have a test that tries to own: com.example.Subtree should succeed com.example.Subtree._1 should succeed com.example.Subtree_1 should fail
*** This bug has been marked as a duplicate of bug 46273 ***
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.