libhal-policy -> PolicyKit

[David Zeuthen]

On Thu, 2006-03-09 at 15:24 -0800, Artem Kachitchkine wrote:
> Close to the truth?

Pretty much I think, thanks for summarizing it! So to recap the policy
format, it should probably look like this

 [Policy]
 Allow=uid:__all__ uid:500 uid:501:somehaludi gid:power_users
 Deny=gid:suspicious_users

 # This per-policy setting overrides the settings and configuration
 # in /etc/PolicyKit/PolicyKit.policy - all keys are optional
 [Auth]
 AuthAllow=true               # whether the user without this privilege 
                              # can auth to gain this privilege

 AuthRequireSUPassword=true   # require super user password for auth

 AuthRequireOwnPassword=false # require users own password for auth

 AuthAllowGrant=false         # whether a user with this privilege can
                              # grant it to other users / groups

 AuthAllowRemove=false        # whether a user with this privilege can
                              # remove it from other users / groups

 AuthModifyAllPolicy=false    # allow user with this privilege to modify
                              # all aspects the policy for the privilege

where /etc/PolicyKit/PolicyKit.policy just contains an [Auth] section
with the keys above. All policies inherit that one but can modify it as
needed. Comments?

I wonder if we should factor in console users in the Allow, Deny
sections and completely remove the "at_console" directive in the HAL
D-BUS policy configuration file (hal.conf). Probably too early to tell..

Btw, I will probably add SELinux support to PolicyKit soon so e.g. 

 Allow=selinux_role:sysadm_r

is valid.. but I really need to read up on SELinux (it's very complex I
think). It will be a compile time option of course. 

One reason for adding SELinux support is to ensure that the whole system
is extensible... so for Solaris you might want include other qualifiers
based on e.g. Authorizations, Privileges etc. For Linux the Capabilities
might also be useful. Would that make sense?

Maybe it would be useful to use PolicyKit in D-BUS configuration files
too, e.g. 

  <policy polkit="some-PolicyKit-policy">
    <allow send_interface="org.freedesktop.Hal.Device.Volume"/>
  </policy>

instead of

  <policy at_console="true">
    <allow send_interface="org.freedesktop.Hal.Device.Volume"/>
  </policy>

though it wouldn't be fine grained enough; e.g. Mount() utilizes four
different policies

 storage-fixed-mount-change-uid
 storage-fixed-mount
 storage-removable-mount-change-uid
 storage-removable-mount

but for some things it might work just fine.

Yea, I'm thinking out loud :-)

> I'm glad Ludwig chimed in yesterday and today's design is much cleaner 
> without those terrible helpers. 

Yea, me too, thanks yourself btw - both your and Ludwig's input have
been very very useful. Patches to implement all this is of course very
welcome :-)

> Will the PolicyKit daemon be implemented 
> as a D-BUS service or something else? 

That's the plan so far, yea.

> Sending the root password over the 
> socket is fine, but could we use PAM over D-BUS?

I think we could yes, but I've never used PAM yet :-). Soon though...

Cheers,
David