libhal-policy -> PolicyKit

[David Zeuthen]

On Wed, 2006-03-08 at 10:38 -0800, Artem Kachitchkine wrote:
> Let me take one step back, 'cause David is way way ahead of what I can grasp in 
> terms of requirements for the feature being designed.
> 
> In the imperfect world around me, authentication and system administration are 
> distinct tasks. Getting information about the rights (authorizations, 
> permissions, privileges, etc) a user has and using these rights is typically 
> lightweight and often transparent. Modifying the rights requires using separate 
> tools, typically requiring to log in to sysadmin account or temporarily assume a 
> syadmin role.
> 
> My limited understanding of David's is that it molds together authentication and 
> system administration. I.e. in the imperfect world of today when I get an "you 
> need privilege XYX you don't have" error, I go and use a sysadmin tool to fix 
> that. In the perfect world of tomorrow, administration will happen at the tip of 
> my fingers in the same UI I'm running the application, by just entering a magic 
> password and clicking "Give me the missing privilege". Is this the idea? I 
> wonder how much simplicity and security is sacrificed to achieve that goal.
> 
> Going back to the use case, the user is asked to enter root password. In an 
> enterprise environment, I don't believe that a sysadmin will be willing to come 
> up to the user's desktop and enter his password. 

Sure, sysadmins for enterprise deployments just turn off annoying popups
like that in gconf. Though, you do agree that we need to explain the
user that they have limited access to files, e.g.

 http://freedesktop.org/~david/perm-override/gnome-mount-perm-override-1.png

right? Otherwise they will waste time finding out the hard way that the
harddisk they attached (which may use HFS+ since it's formatted on a
Mac) is next to unreadable for them.

So.. I think in an enterprise deployment we'll just reconfigure the
libpolkit-GNOME password dialogs to say "Request Privileges from
Sysadmin Team" instead of giving them dialog here

 http://freedesktop.org/~david/perm-override/gnome-mount-perm-override-2.png

User clicks and a mail is automatically prepared and sent to the
sysadmin request queue. The email address (or whatever transport
endpoint is used to automatically send the request, e.g. RequestTracker,
Bugzilla, whatever) should also just be read from gconf - this will
probably be a locked down setting...

Of course, some sysadmins might configure libpolkit-GNOME to neither
provide dialogs nor send requests. That is fine too. It's their network,
it's their choice.

> In a personal desktop 
> environment, I am so happy to see the need for the root password and account 
> being reduced: e.g. I don't believe I ever needed a root password in Ubuntu, I 
> just use my own password to acquire privileges that are permitted for me, but 
> not granted by default. How will this fine model going to be affected by polkit?

I indeed want PolicyKit to be able to auth the user against his own
password instead of the root password and, for the record, I want this
to be the default in the PolicyKit tarball (though we may patch this to
be the root password for Fedora). This should be configurable in a
configuration file for libpolkit. 

But in SOHO/SMB deployments it might be useful to ask for the root
password since the sysadmin is available to manually service all
workstations (and the Small Office don't use a request tracker system
etc.).

Another problem... what really motivated me to make all this noise.. is
that most vendors ship a general purpose operating system and sometimes
it's difficult to provide a default configuration that all kinds of
users are happy with. That's why I want the one-time-pain dialogs that
allow users to gain and earn privileges. (Of course, allowing users to
permanently acquire a privilege should probably be another privilege in
itself :-)

I also want the default security we ship with HAL is somewhat secure for
a general purpose system. Yes, this includes asking for auth when
formatting removable media I think. Of course, in e.g. Fedora we may
tweak this in the OS installer if then user selects the install class
named "Personal Laptop"; then they get many more privileges.. on the
contrary if the install class is "Server" desktop users might have to
auth with the root password just to mount a disk or reboot the system.
*Shrug*.

Trust me, I don't want to expose users to any of these auth dialogs if I
can avoid it. 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.

Does this explain a bit better what I'm trying to achieve? I hope so :-)

     David