libhal-policy -> PolicyKit

Artem Kachitchkine Artem.Kachitchkin at Sun.COM
Wed Mar 8 12:59:57 PST 2006

> like that in gconf. Though, you do agree that we need to explain the
> user that they have limited access to files, e.g.

Absolutely, no problem with that at all.

> I indeed want PolicyKit to be able to auth the user against his own
> password instead of the root password and

Then how would he be able to modify the policy? If an agent does it for 
him, then, indeed, as you say "allowing users to permanently acquire a 
privilege should probably be another privilege in itself" and is it 
something that a sane sysadmin would allow? How does he limit which 
privileges does he have a privilege to acquire? Is there really a 
fundamental difference between temporary and permanent, or a kind of 
difference we want to maintain? All sorts of difficult questions arise 
from such recursion.

> But I also don't want a situation where things are not
> fixable for a user unless the sys admin explicitly configured the system
> for this. That's just bad and leaves the user in the cold.

Well, I understand the problem, but not the solution. What bothers me is 
the dangerous dance we perform with D-BUS auth, PAM, PolicyKit's own 
policies and system-wide policies (which are so different in different 

Perhaps we could improve configuration tools instead? E.g. when the user 
installs a system and says "This is a personal system and the only 
sysadmin here is me", then when a privilege is missing, launch an 
administration GUI du jour, passing the privilege name, so the GUI does 
the smart thing brings the user directly to it. Of course, following you 
description, I could patch libpolkit-GNOME in Solaris to do exactly 
that, but that kind of makes GNOME experience less coherent across 
platforms. I think the general direction right now is to unify desktops.


More information about the hal mailing list