Do not auto-activate services if we could not send a message
authorSimon McVittie <simon.mcvittie@collabora.co.uk>
Mon, 21 Nov 2016 20:56:55 +0000 (20:56 +0000)
committerSimon McVittie <simon.mcvittie@collabora.co.uk>
Mon, 28 Nov 2016 12:11:41 +0000 (12:11 +0000)
commit373cc47c7c50adb1b624526cfa452d52954621a5
treef27305cd14ef4727a79572145c47d9f79f959ec8
parent5503511f91a66f0888937690e95d85100bcde4e4
Do not auto-activate services if we could not send a message

We specifically do not check recipient policies, because
the recipient policy is based on properties of the
recipient process (in particular, its uid), which we do
not necessarily know until we have already started it.

In this initial implementation we do not check LSMs either,
because we cannot know what LSM context the recipient process
is going to have. However, LSM support will need to be added
to make this feature useful, because StartServiceByName is
normally allowed in non-LSM environments, and is more
powerful than auto-activation anyway.

The StartServiceByName method does not go through this check,
because if access to that method has been granted, then
it's somewhat obvious that you can start arbitrary services.

Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98666
bus/activation.c
bus/apparmor.c
bus/apparmor.h
bus/bus.c
bus/bus.h
bus/connection.c
bus/dispatch.c
bus/policy.c
bus/selinux.c
bus/selinux.h
test/sd-activation.c