libhal-policy -> PolicyKit

Artem Kachitchkine Artem.Kachitchkin at Sun.COM
Thu Mar 9 17:33:21 PST 2006

> That's a nice thought and it it's a nice goal. Let's see where we
> currently ask for the root password in my Fedora Rawhide system.

In Solaris we don't ask for root password at all for administration 
tasks. Rather, we allow admins to tune profiles and/or roles to their 
liking. Here's an example of a Solaris admin with a use case of managing 
SMF services (technology we use instead of init scripts):

The second worst thing a sysadmin can be asked for is the root password 
on a system. [...]

Lets take a quick example. Say that I want to manipulate SMF services 
without having to become root all the time. I notice that SMF has 
authorizations in the /etc/security/auth_attr database, as well as 2 
profiles that map those authorizations in /etc/security/prof_attr. I can 
associate the auths directly with my user account or use the profiles, 
but for cleanliness I'll use a profile. So lets try it:

benr at monolyth benr$ svcadm disable svc:/network/talk:default
svcadm: svc:/network/talk:default: Permission denied.

Now I add the following line to /etc/user_attr: 
"benr::::profiles=Service Management". Lets try it again.

benr at monolyth benr$ tail -1 /etc/user_attr
benr::::profiles=Service Management
benr at monolyth benr$ svcadm disable svc:/network/talk:default
benr at monolyth benr$ svcs svc:/network/talk:default
STATE          STIME    FMRI
disabled       15:10:17 svc:/network/talk:default

Kool. Now I can bring services up and down without having to become root 
all the time.

Profiles nicely group authorizations and privileges such that you can 
get a functional least-privilege environment.

It would be nice if I could tie this system with GNOME applications 
using libpolkit as an abstraction layer.


More information about the hal mailing list