Do not auto-activate services if we could not send a message 07/193007/2 accepted/tizen/unified/20181115.151616 submit/tizen/20181115.015729
authorSimon McVittie <simon.mcvittie@collabora.co.uk>
Mon, 21 Nov 2016 20:56:55 +0000 (20:56 +0000)
committerHyotaek Shim <hyotaek.shim@samsung.com>
Thu, 15 Nov 2018 03:19:01 +0000 (03:19 +0000)
commit83d1082e192ddaad5602e9c9e3e7398f6d6d1938
tree31a1fb71b84a23f7c13c1416c5e611cbe101d810
parent3685060543e59acc45b3aa7ce5077069bb337365
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

Change-Id: I53ff4f6d02e631fcd09bf1c5c306b8828f075963
12 files changed:
bus/activation.c
bus/apparmor.c
bus/apparmor.h
bus/bus.c
bus/bus.h
bus/check.c
bus/connection.c
bus/dispatch.c
bus/policy.c
bus/selinux.c
bus/selinux.h
test/sd-activation.c