about using privileged (KAuth) helpers: system dbus daemon on OS X?

René J.V. Bertin rjvbertin at gmail.com
Sun Sep 18 21:39:36 UTC 2016


On Sunday September 18 2016 09:32:35 Thiago Macieira wrote:

> > So is it normal that the helper process is launched by the system dbus? If
> > so, can someone please explain how the helper procedure is supposed to play
> > out at the level of dbus communication?
> 
> dbus-daemon launches helper, helper sets the environment up to avoid any leak 
> of information from the daemon but also to setuid correctly, then execs the 
> target process.

I think your "target process" is what I've been calling the privileged helper, right? As far as I've understood from the code, dbus-daemon uses dbus-daemon-helper-tool to launch the helper required for the user's request. dbus-daemon-helper-tool is setuid root, meaning that anything exec'ed by it should have uid==euid==0 (or else it must do setuid(geteuid())). The helper would need to have uid==euid in any case, otherwise Qt or libdbus will typically refuse to work, and if it doesn't have euid==0 it wouldn't be privileged.

So we have a user application (say, ksysguard) that calls DBus routines to launch a privileged helper process (ksysguardprocesslist_helper), a master and a (special :)) slave. The slave expects to connect to a dbus, presumably to receive additional requests from the master, and to report back. That part is handled by KAuth's DBus helper backend, so a hidden aspect of the KAuth API. It's also the part of which I fail to understand how it can work.

Is it the dbus-daemon-helper-tool setting-up of the environment that ensures that the ksysguardprocesslist_helper can connect to the user's session dbus? 
If so, how? dbus-daemon-helper-tool is supposed to run with the user's UID and EUID=0, but if it can read the user's DBUS_SESSION_BUS_ADDRESS, why can its children not read it?

Then there's the fact the system dbus runs as yet another user ("messagebus"; 102 on my Linux box, 500 on OS X) and that's probably the UID with which the dbus-daemon-helper-tool runs. 

If the privileged helper (slave) is supposed to connect to the system dbus when launched via dbus-daemon-helper-tool, how/why does it do so on Linux?

NB: forcibly pointing the slave to the system dbus socket also provides a working solution:
%> sudo launchctl setenv DBUS_LAUNCHD_SESSION_BUS_SOCKET "unix:path=/opt/local/var/run/dbus/system_bus_socket"

R.


More information about the dbus mailing list