[Bug 46882] Make per-connection bus names non-mandatory
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Mar 2 11:41:55 CET 2012
https://bugs.freedesktop.org/show_bug.cgi?id=46882
--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-03-02 02:41:55 PST ---
(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.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the telepathy-bugs
mailing list