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

[René J.V. Bertin]

On Monday September 19 2016 13:31:12 Thiago Macieira wrote:

> It's very rare to find an application that uses the starter bus concept.
> 
> Most applications are designed for exactly one bus and will connect to that. 
> Having them work on either system, session or a custom bus simply isn't done.

I can only suggest you look at the KAuth code (without expecting you to, of course). I've got only a very limited understanding what it actually does behind the scenes: what documentation there is beyond the source-level comments does a great job at hiding the hairy details from the developer, focusing instead on how simple to use it is.
What people there are who really understand what the code does apparently don't read the mailing lists on which I asked for some guidance.

That's not to say that that KAuth service execs use the starter bus concept. If using that means that they'd connect to either bus they can find then they may use something else, because I don't think that they connect to anything but the system bus.

I only asked about the starter bus because the DBUS_STARTER env. variables are set by the dbus-daemon-helper-tool which also launches the service execs. If they're only ever set by that helper they provide a straighforward way to determine which bus to connect to.

> Cross-platform software should be written to use the native system services,
> not rely on a Linux equivalent software to have been ported to the OS in
> question and wrap the native API that the OS already provided.

You're not wrong, but I'd make an exception for software in distribution systems like MacPorts, Fink etc. which isn't necessarily cross-platform by design. 
KDE software intended to be truly cross-platform will indeed aim to limit its dependence on DBus, but that's not so easy for all code.

> Elevating privileges is a native OS operation because, by definition, you're
> doing some kind of system administration. I don't think there should be a
> cross-platform solution for this. If you're going to do system
> administration, write platform-specific code.

Except that OS X is still a Unix OS, so DBus doesn't do anything non-native in starting a privileged service. What that service does is another matter, but the native OS X API to start a privileged helper process is based on the same BSD calls DBus uses. One difference: the Security framework had (a now deprecated) function to start any executable with the setuid set transiently, which removed the need for a separate setuid proxy.

As I said, I may decide to write a more native helper backend for KAuth, to compliment its native authentication backend. But whether I'll do that will depend on how much the required effort is justified by need. If this will be used by only a few applications that in any case cannot do without DBus, then it will be much more reasonable to make the DBus backend work as smoothly as possible.

> System bus, however, hasn't made sense on those OSes. That's why there is no
> way to autolaunch them on Mac and Windows.

The system dbus can be autolaunched the same way as the session dbus on OS X, with a launchd plist. It just has to be registered for auto-launching by root.

R.