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

On segunda-feira, 19 de setembro de 2016 23:31:28 PDT René J.V. Bertin wrote:
> 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.

I'm not going to read its source, sorry.

> 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.

Probably because the tool was "properly" designed to take that into account, 
but it's a wholly untested territory. Like I said, no one uses the starter 
bus.

> > 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.

MacPorts and HomeBrew need to select software that has been ported to run on a 
Mac. For example, any software that depends on systemd or journald will not 
compile and will not run on macOS, so MacPorts should not include them.

> > 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.

macOS also has some privilege separation and integrity protection systems that 
you neeed to take into account. So it's not the regular BSD APIs.

PS: Apple renamed their OS. It's now called "macOS".

> > 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.

Technically, it can. The question is not on the practical matters, but whether 
it makes sense to. When I said that it hasn't made sense, I meant that there 
were no services to be found there.

And if a macOS is so Unix, why can't you start it at boot like on a regular 
BSD?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus