Sune Vuorela wrote:
> I know nothing about mac, and only have a limited knowledge of KAuth, on
> linux, but I'll give it a go replying anyways.
Thanks, that's a start :)
> Whenever an application wants something that requires elevated
> priviledges, it contacts policykit, that does the authorization and
> execution as the relevant user.
Are you sure it always does the actual execution? It comes with pkexec, but
has a similar tool, and it seems to stand to reason that's the one DBus uses to
launch privileged helpers...
> Thus, there is no setuid bits in place.
Except on pkexec and dbus-daemon-helper-tool ... I *presume* that the euid!=uid
aspect you get inside a setuid process isn't inherited by any child that
spawns, but I have yet to verify that.
> 2) How is the platform API for invocating things as a different user /
> with admin priviledges?
> - then implement a kauth backend on top of that api.
That's the annoying bit: the straightforward API is deprecated, and replaced
with something involving launchd. I think it'll be much easier and more
to implement a helper backend that comes with its own setuid proxy.
The Service Management framework that would be the modern alternative is
cumbersome to deploy, requiring code-signing of all parties involved among
> I'd say that on a linux system, the kauth bits is mostly relevant to
> - systemsettings and related KCM's
There might be a selected few KCMs requiring privileges that make sense outside
> - special hardware requiring applications. Maybe KStars interacting
> with a telescope, or a theoretical KAdvancedSewingMachine, K3DPrinter
> or similar.
What would they need privileges for that cannot be taken care of by a native
An example might be a KF5 frontend to VirtualBox (or simply VirtualBox calling
upon KAuth). Running a VM with a "raw" (direct access) .vmdk disk image
currently requires making the disk device file user-writable manually on OS X
(or running with admin privileges on MS Windows); this could be taken care of
automatically by the front-end.