When "activating" systemd, handle its special case better
authorChengwei Yang <chengwei.yang@intel.com>
Wed, 29 May 2013 12:50:21 +0000 (20:50 +0800)
committerSimon McVittie <simon.mcvittie@collabora.co.uk>
Wed, 5 Jun 2013 16:27:48 +0000 (17:27 +0100)
commitb434238c346a356b7aee4e43a9b88c1df1d4aef5
tree203917ce0c6f58a48075ad1dc285c6f939a3903f
parent1d560ff7f98880d06e4667936611beca802bd651
When "activating" systemd, handle its special case better

When dbus-daemon receives a request to activate a systemd service before
systemd has connected to it, it enqueues a fake request to "activate"
systemd itself (as a way to get a BusPendingActivationEntry to track the
process of waiting for systemd). When systemd later joins the bus,
dbus-daemon sends the actual activation message; any future activation
messages are sent directly to systemd.

In the "pending" code path, the activation messages are currently
dispatched as though they had been sent by the same process that sent
the original activation request, which is wrong: the bus security
policy probably doesn't allow that process to talk to systemd directly.
They should be dispatched as though they had been sent by the
dbus-daemon itself (connection == NULL), the same as in the non-pending
code path.

In the worst case, if the attempt to activate systemd timed out, the
dbus-daemon would crash with a (fatal) warning, because in this special
case, activation_message is a signal with no serial number, whereas the
code to send an error reply is expecting a method call with a serial
number.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=50199
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Tested-by: Ma Yu <yu.ma@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
bus/activation.c