D-Bus service, forking and shared service name

[Simon McVittie]

On Fri, 26 May 2017 at 16:14:36 +0200, David Sommerseth wrote:
> We would prefer to have a unified bus name (net.openvpn) which is used
> across all our processes.  Each configuration and running tunnel should
> then have a unique object path, with their own set of methods.

Sorry, you can't do that. If you think of well-known bus names as being
like hostnames, and object paths being like HTTP paths, that's close to how
it works.

You can have several web servers trying to implement the same hostname,
but if you do, you don't get to decide which one handles a request
from a client - so in practice it doesn't make sense unless they all
serve the same content. Semi-similarly, you can have several D-Bus
processes[1] trying to own the same well-known bus name, but they'll
be in a queue, and only the process at the front of the queue (the
current owner) actually gets to handle requests from clients.

The closest you can get to this is one of these two approaches:

* Have objects in the net.openvpn main process that represent the
  actual tunnels. Clients communicate with those objects. When clients
  call methods on those objects, the main process implements those
  methods by calling methods on the individual tunnel processes
  (effectively it's behaving like a proxy). It could pass
  requests straight through without understanding them if you
  want it to, but it would be more common to have it interpret
  the method calls and have their implementation be implemented
  in terms of further method calls.

  Prior art: NetworkManager exposes D-Bus objects for connections, and
  some of those objects are implemented in terms of calling D-Bus
  methods on dnsmasq and/or wpasupplicant instances.

-or-

* Wherever you would expect a method in the net.openvpn main process to
  return an object path, if it might be in a different process, either
  return a (bus name, object path) pair instead or have a documented
  rule for deriving a bus name from the object path. Clients are
  expected to communicate with the actual tunnel process using the
  given bus name.

  Prior art: The Telepathy AccountManager creates connections which
  are in "connection manager" processes distinct from the AccountManager.

To get D-Bus access control to work well, you will probably find that
you want all your service processes (except for perhaps the main one)
to get in the queue for a special well-known bus name like
net.openvpn.anytunnel that is not actually intended to be used in
any method calls. The reason you should probably do that is that it
can be used in access-control decisions: the dbus-daemon policy language
understands <allow send_destination="com.example.foo"> to mean
"allow sending messages to any process that *is in the queue to own*
the com.example.foo name", not just the process that currently owns
the name (i.e. is at the front of the queue) like you might expect.

Regards,
    S

[1] Technically, connections to D-Bus (usually AF_UNIX sockets) rather
    than processes; but in practice if the same process has more than
    one connection to the same bus, something has probably gone wrong.
    You cannot share a connection to D-Bus between processes; well,
    technically you can via fd inheritance, but it will not work as
    intended (or work at all, really) and this is not a supported action.