D-Bus policies. system bus and bus names

[David Sommerseth]

Hi again,

I'm still trying to wrap my head around how using process generated bus
names.  I'm basing this on the suggestions from Simon.

What I have now is a process which is capable of owning its own bus
name, generate the needed objects and is ready to be managed.  But since
the process uses the system bus and have a unique name per process, I'm
struggling to get the policies right.

An example, here's an introspection I've had to "lure" out of D-Bus
through a policy hack [1]:

------------------------------------------------------------
node /net/openvpn/v3/backend/sessions/8db5bac8z4885 {
  ... skipping org.freedesktop.DBus interfaces ...

  interface net.openvpn.v3.backends {
    methods:
      Start();
      Pause();
      Restart();
      Disconnect();
    signals:
    properties:
      readonly s Status;
  };
};
------------------------------------------------------------

In this case, the bus name is: net.openvpn.v3.backends.be7594

The policy I had to apply to make this work, is what the dbus-daemon
strongly advices against.

    <allow own_prefix="net.openvpn.v3.backends"/>
    <allow send_interface="net.openvpn.v3.backends"/>

The first line is probably fine, and it allows the process to generate
the unique bus name.  But the second one is truly my biggest concern -
and the man page explicitly tells me NOT to only use send_interface in
an allow or deny rule.

The trouble is that it seems to be lacking a send_destination variant
similar to own_prefix.

If I try this on the session bus, the policies doesn't seem to cause any
challenges at all.

The master plan is that an "openvpn management daemon" is first started.
 A front-end client (which the user interacts with) passes a
configuration to this daemon over D-Bus, and tells it to start a tunnel
with that configuration.  This management daemon forks out and
"daemonizes" before and then starts the tunnel operations.  A part of
the "daemonizing" is also to establish a link over D-Bus between the
"management daemon" and the "tunnel/session daemon".

All this said, the "tunnel/session daemon" doesn't need to be on the
system bus.  But I'm concerned what happens if the "management daemon"
dies or gets restarted if the session bus is used.  Who does that
session bus belong to?  I do want to be able to have a possibility to
recover properly while avoiding tunnel interruptions.

By the way, I'm targeting RHEL7 as the "oldest" Linux distribution to be
supported.  And that is based on the d-bus-1.6.12 baseline (with a
handful of backported fixes).


Any suggestions?  Ideas?


[1] D-Bus introspection policy hack:
    <allow send_interface="org.freedesktop.DBus.Introspectable"/>

-- 
kind regards,

David Sommerseth