Bug 46882

(In reply to comment #0)
> In the current spec, each Connection object must get its own, dynamically
> composed, bus name.

The original rationale for this was that it supports CMs implemented using a library that can only make one connection per process. On RequestConnection, such a CM could take a bus name for its Connection (perhaps with its process ID in the name), then drop its ConnectionManager name. When a second connection was requested, dbus-daemon would activate a new copy of the CM to handle the second RequestConnection call, and so on.

In practice we've never actually either done that, or wanted to do so...

The other purpose of the Connection bus names was to act as a mutex to avoid having two attempts to connect to the same account at the same time, but that proved to be more trouble than it was worth, so we now make the bus names unique (IIRC).

(In reply to comment #0)
> This does not work well on a bus where arbitrary name ownership is prohibited
> by policy: while we can easily punch holes for connection manager names, the
> connection names are not known statically, and partial name matching is not
> currently supported by dbus-daemon policies. Citing dbus-daemon(1):
> 
>        Complex  globs  like  "foo.bar.*" aren't
>        allowed for now because they'd be work to implement and maybe encourage
>        sloppy security anyway.

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.

I've seen others on #dbus wanting this functionality for the system bus: they want to restrict name ownership for all instances of a multiple-instance service.

> the preferred way to
> enumerate Connection objects on the bus could be changed to listing
> ConnectionManager services and then enumerating Connection objects on these
> services. The requirement for a Connection to register its own bus name can be
> relaxed to "SHOULD (for backwards compatibility)".

That would be a possibility. It breaks the original use-case for connections working like this (not that that's necessarily a problem, given that we've never implemented it).

> The implementation of
> TpBaseConnection in telepathy-glib can then be changed to treat the failed name
> ownership request as non-fatal (and get rid of one more complete bus roundtrip
> needed to initalize a connection).

TpBaseConnectionManager would have to keep a global registry of Connections by object path (or use more modern libdbus API, try_register), to avoid trying to register two connections at the same object path and crashing itself; at the moment the bus name acts as a mutex, preventing this.

(In reply to comment #1)
> The original rationale for this was that it supports CMs implemented using a
> library that can only make one connection per process. On RequestConnection,
> such a CM could take a bus name for its Connection (perhaps with its process ID
> in the name), then drop its ConnectionManager name.

I suspected something like that. But that either presents a race condition, or requires all clients to gracefully handle a "can't do it now, try again later" error for RequestConnection. So this doesn't seem like it can work reliably with current client software.

> 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.

That would be great, and perhaps bring more good to the universe than tweaking Telepathy would do.

> TpBaseConnectionManager would have to keep a global registry of Connections by
> object path (or use more modern libdbus API, try_register), to avoid trying to
> register two connections at the same object path and crashing itself;

In practice, object paths are now randomized too, right?

> at the moment the bus name acts as a mutex, preventing this.

Well, then it's an expensive socket-served mutex for purely local state, so it can hardly be the primary purpose.

(In reply to comment #2)
> In practice, object paths are now randomized too, right?

They correspond 1:1 to the bus names, so, yes.

> > at the moment the bus name acts as a mutex, preventing this.
> 
> Well, then it's an expensive socket-served mutex for purely local state, so it
> can hardly be the primary purpose.

Right, this is not their primary purpose, just making use of a side-effect; if we lose the bus names, we'd have to find a different (probably purely local) solution for object path uniqueness.

Another property provided by the bus names is that they guarantee that connections' object paths are unique within the session (because uniqueness of bus names is enforced by the dbus-daemon, and the object paths correspond 1:1 to bus names). This lets you refer to a connection by its object path only, knowing that that's enough to refer to it uniquely and find its bus name (for instance, Account.Connection relies on this).

To drop the Connection bus names we'd have to have another way to find the bus name, probably by requiring that the Connection /o/fd/T/Connection/foo/bar/baz owns the well-known name "o.fd.T.ConnectionManager.foo".

Thanks for the explanation; this looks like a bigger can of worms than adding a feature to dbus-daemon (filed as bug #46886).