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