1D-BUS System Activation
2
3Introduction:
4
5The dbus-daemon runs as the dbus user, and is therefore unprivileged.
6Earlier attempts [1] by David Zeuthen at launching system scripts using a
7custom DBUS protocol were reviewed, but deemed too difficult to audit, and
8also due to a multi-threaded design, too difficult to test.
9In the next few paragraphs I will outline a simpler setuid approach for
10launching daemons as a configured user.
11
12Scope:
13
14Launching programs using dbus has been a topic of interest for many months.
15This would allow simple systems to only start services that are needed,
16and that are automatically started only when first requested.
17This removes the need for an init system, and means that we can trivially
18startup services in parallel.
19This has immediate pressing need for OLPC, with a longer term evaluation for
20perhaps Fedora and RHEL.
21
22Details:
23
24Setuid applications have to used only when absolutely necessary.
25In this implementation I have an single executable,
26dbus-daemon-launch-helper, with the ownership root:dbus.
27This has the permissions 4750, i.e. u+rwx g+rx +setuid.
28It is located in /usr/libexec/ and thus is not designed to be invoked by a
29user directly.
30
31The helper must not be passed input that can be changed maliciously, and
32therefore passing a random path with user id is totally out of the question.
33In this implementation a similar idea as discussed with Davids' patch was
34taken, that to pass a single name argument to the helper.
35The service filename of "org.me.test.service" is then searched for in
36/usr/share/dbus-1/system-services or other specified directories.
37
38If applications want to be activated on the system _and_ session busses, then
39service files should be installed in both directories.
40
41A typical service file would look like:
42
43[D-BUS Service]
44Name=org.me.test
45Exec=/usr/sbin/dbus-test-server.py
46User=ftp
47
48This gives the user to switch to, and also the path of the executable.
49The service name must match that specified in the /etc/dbus-1/system.d conf file.
50
51Precautions taken:
52
53* Only the bus name is passed to the helper, and this is validated
54* We are super paranoid about the user that called us, and what permissions we have.
55* We clear all environment variables except for DBUS_VERBOSE which is used for debugging
56* Anything out of the ordinary causes the helper to abort.
57
58Launching services:
59
60Trivial methods on services can be called directly and the launch helper will
61start the service and execute the method on the service. The lauching of the
62service is completely transparent to the caller, e.g.:
63
64dbus-send --system --print-reply			\
65	--dest=org.freedesktop.Hal			\
66	/org/freedesktop/Hal/Manager			\
67	org.freedesktop.Hal.Manager.DeviceExists	\
68	string:/org/freedesktop/Hal/devices/computer
69
70If you wish to activate the service without calling a well known method,
71the standard dbus method StartServiceByName can be used:
72
73dbus-send --system --print-reply			\
74	--dest=org.freedesktop.DBus			\
75	/org/freedesktop/DBus				\
76	org.freedesktop.DBus.StartServiceByName		\
77	string:org.freedesktop.Hal uint32:0
78
79[1] http://lists.freedesktop.org/archives/dbus/2006-October/006096.html
80
81