libhal-policy -> PolicyKit

[David Zeuthen]

Hi,

I just moved the libhal-policy bits into a separate CVS repo / tarball
named PolicyKit. It's available from the hal CVS repo

 http://webcvs.freedesktop.org/hal/

This was done since these bits weren't really hal specific and they may
be useful for other things beyond HAL. I will also add more bits and
utilities to PolicyKit in the future with the use cases mentioned in

 http://lists.freedesktop.org/archives/hal/2006-January/004377.html

in mind. 

One thing that comes to mind is a tool that I want to call polkit-su
that enables e.g. desktop apps to easily become an otherwise
unprivileged user, polkit (user required for PolicyKit), that has wider
and less restricted access to D-BUS methods on e.g. HAL.

Clearly polkit-su should be written in a secure way and either require
the root password or the users own password (can and should be
configurable) through stdin before becoming that user after auth through
e.g. PAM or /etc/passwd. Kinda like /bin/su actually. Read on before
flaming me please :-)

What ultimately inspired me to take this task upon me is the rather
broken state of 'su' graphical frontends (usermode/consolerhelper on
Fedora, gnomesu/xsu, gksu(do) to name three) available today. There are
several problems with these

 - They all permit X applications to run as root. This is just plain
   wrong on so many levels;

   - you have to audit the toolkit and image loaders; this is simply
     not very feasible; GTK+ alone is 500,000+ lines of code

   - it encourages to just run system tools as root just such that
     system-wide files can be modified etc - just look at Fedora
     and the system-config-* tools

 - Existing tools don't have wide adoption

 - The 'su' problem should be solved upstream in a saner way than
   what is available today

So the thinking is to let desktop apps only su to an unprivileged user
(polkit) and execute a program that runs in a controlled environment
without access to the X server or local session bus. 

To do useful work obviously the program that is to be executed needs to
use D-BUS or similar and speak to a (system-wide) process with more
privileges. HAL, for instance.

I kinda don't like to take this task upon me but I don't see any other
way to solve these problems in a sane way. Flames and suggestions
welcome :-). /me puts on burn-proof pants.

    David