about using privileged (KAuth) helpers: system dbus daemon on OS X?
René J.V. Bertin
rjvbertin at gmail.com
Fri Sep 23 10:54:32 UTC 2016
On Friday September 23 2016 11:24:16 Simon McVittie wrote:
> However, I suspect that a better way to have a system bus on OS X, if
> one is genuinely useful, would be to use a fixed Unix socket address in
> a directory controlled by the sysadmin and unavailable to ordinary
> users, just like what's done on other Unix platforms. You can already do
> this: make your system bus listen on
Indeed, and that works as one would expect. The only issue here is using it from a privileged service that is launched with a minimal environment. The way the current init routines work the bus_connection_addresses entry for the session bus remains empty, which is considered an error before it is even known that that address is going to be used.
I think that issue would persist even if we added a more Mac-like way of starting a system bus (see below about that).
On Linux, missing entries in bus_connection_addresses will be set to "autolaunch:" by a codepath that isn't taken when libdbus is built with launchd support; this value really only serves as a placeholder in this particular situation, as the actual autolaunch never takes place.
The obvious way around is to run a session bus for root, but that's not very elegant. A more hackish approach is to do something like `sudo launchctl setenv DBUS_LAUNCHD_SESSION_BUS_SOCKET foo` (or "unix:path=/dev/null" instead of foo). The basic init routines then succeed, and the privileged client can connect to the system bus as it intended to do.
I'm currently testing another patch, which handles the missing bus address situation at a level where more information is available. Instead of relying on an unused "placeholder" address, the ENABLE_LAUNCHD version checks if the bus_connection_addresses entry for the requested bus exists. That should result in the same connection behaviour. An alternative patch could return specific invalid addresses in that array, in launchd builds, if that's more acceptable.
I just realised it would also work if the daemon-helper-tool sets DBUS_LAUNCHD_SESSION_BUS_SOCKET to the system bus address (when built with launchd support). That would again only be a placeholder value, but one that doesn't seem entirely out of place. A process running as root to perform a well-defined privileged operation runs in what one could call a system session (which ends the moment the operation is finished), no?
This is being discussed as a MacPorts trac ticket: https://trac.macports.org/ticket/52257 ; I personally do not have any way to add the DBus ML address to that ticket's CC: list. Note that the proposed patch includes a launchd plist for starting a system bus, so I don't think it would be justified to design another launchd protocol using for instance a DBUS_LAUNCHD_SYSTEM_BUS_SOCKET env. variable.
More information about the dbus