libhal-policy -> PolicyKit
Artem.Kachitchkin at Sun.COM
Thu Mar 9 15:24:34 PST 2006
> So users authorize with their own passwords (which they already did when
> they logged in). How does PolicyKit daemon determine if a user can gain
> a privilege he doesn't currently have?
To answer my own question: it depends on how the system is configured
and what authentication methods are in place, which is good.
I looked at the existing su front-ends, re-read this whole thread and I
think it now makes more sense. David started by stating that running X
programs linked against huge unaudited toolkits as root is bad. D-BUS
gives us remote procedure calls in the form of methods and per-method
Privilege escalation occurs only when the D-BUS service is privileged
(which HAL is). Right now, HAL methods can be either allowed to all, or
to root, or to console user - policy kit simply extends this mechanism.
To summarize so far: sudo lets me run an application with extra
privileges; polkit-su lets me run individual "subroutines" in an
application with extra privileges.
But wait, there's more. In addition to this being "sudo for routines",
we also throw in a daemon that would allow us to change policies on the
fly, instead of editing the files. The daemon has privileges to write
into the policy database, and will gladly accept a root password.
Close to the truth?
I'm glad Ludwig chimed in yesterday and today's design is much cleaner
without those terrible helpers. Will the PolicyKit daemon be implemented
as a D-BUS service or something else? Sending the root password over the
socket is fine, but could we use PAM over D-BUS?
More information about the hal