[PATCH 3/3] activation: optionally, use systemd for system bus activation

[Lennart Poettering]

On Wed, 07.07.10 16:32, Colin Walters (walters at verbum.org) wrote:

> On Wed, Jun 23, 2010 at 12:12 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> 
> > +  if (dbus_message_is_signal (message, "org.freedesktop.systemd1.Activator", "ActivationFailure"))
> > +    {
> > +      BusContext *context;
> > +
> > +      context = bus_connection_get_context (connection);
> > +      return dbus_activation_systemd_failure(bus_context_get_activation(context), message);
> > +    }
> > +
> 
> I don't like having a magic signal that the bus processes here.
> There's no checking of the sender which is clearly wrong.

Hmm, I need to investigate that further.

> Coincidentally I was thinking earlier today it'd be nice if the bus
> had a "private" management interface on a separate socket.  Say
> /var/run/dbus/system_bus_admin_socket.  That could be locked down
> cleanly and separately from the system bus, and we could add hidden
> interfaces there for e.g. systemd integration, rather than exposing
> them to the world as a stable interface.

I actually like to keep everything on one bus. The bus is just a
transport, and i see little need to split off a seperate connection only
for the activation stuff.

Note that keeping things on a single bus has a big advantage: the
activation logic can be used for "activating" systemd itself. There's
otherwise a race: when systemd knows the bus is up, it connects to it
offering its activation services. However, before that is complete there
is a short time window where other clients might haven overtaken systemd
and have asked for systemd's APIs, or the activation logic needs
systemd, but systemd is not yet full available on the bus. By using the
activation logic for waiting for systemd itself allows us to fix that
race. i.e. here's an example which hopefully illustrates how the current
patch fixes this race:

1. D-Bus is started
2. Application "Foo" connects to it, asks for service "Bar"
3. D-Bus finds that "Bar" is not yet on the bus but is configured for
   activation via systemd. So it sends out the activation request to the
   systemd service, and queues the request.
4. D-Bus finds that systemd is not yet on the bus, so the activation
   request is queued too via the activation system and it is waited that
   systemd connects.
5. systemd catches up and connects
6. D-Bus delivers the queued activation message to systemd, and systemd
   processes that.
7. The "Bar" service becomes available on the bus.
8. D-Bus delivers the other queued activation message to "Bar"
...

Also note that the messages exchanged are in the
org.freedesktop.systemd1.Activator namespace, which should make
sufficiently clear that those messages are specific to systemd -- and
only systemd -- and only make sense for its very own semantics.

So, I'd really like to stay with the current approach, but I guess 
the security problem you pointed out matters.

> The multiple sockets trick plays well with SELinux too; I'm pretty
> sure libvirt does this.
> 
> > +  fprintf (stderr, DBUS_DAEMON_NAME " [--version] [--session] [--system] [--config-file=FILE] [--print-address[=DESCRIPTOR]] [--print-pid[=DESCRIPTOR]] [--fork] [--nofork] [--introspect] [--address=ADDRESS] [--systemd-activation]\n");
> 
> Kind of gross.  I'd honestly prefer just a configure switch
> --with-activation=systemd or something.  Why make it a runtime option?

To make it possible to boot the same system with systemd and without
systemd: the systemd .service file would set --systemd-activation and
thereby tell D-Bus that it should send activation requests to
systemd. And the SysV init script would not set it, so that when D-Bus
is started with a traditional init system this activation hookup would
not happen.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.