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
OSes).
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.
-Artem.
More information about the hal
mailing list