libhal-policy -> PolicyKit

[Artem Kachitchkine]

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

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?

-Artem.