Gary Winiger wrote:
>>4. Technical Description
> 
> 
>       I see a number of cases referred to but no case dependencies.
>       Is that because all the referred to cases are either integrated
>       or dependent on this case?

Yes and yes.

> 
>       For all of these actions, what is the default value?

For lid, the default is to do nothing.
For power button, the default is to ask the user with gnome-sys-suspend.

>       For all of these actions, what happens if the user isn't
>       authorized?
> 

If the user is not authorized, the action is not available by GPM.

> 
>>available if supported by the system.  In addition, the actions
>>will be allowed if the user is the console owner or has the appropriate
>>RBAC authorization. 
> 
> 
>       What is the definition of "console owner"?  Perhaps see
>       PSARC/2008/034 Defining Workstationn Owner Infrastructure.

Console owner is the owner of /dev/console.  I would like to use the
Workstation Owner role, but didn't want to be dependent on it without
knowing the schedule.

> 
> 
>>Security
>>--------
>>Interface level: Volatile
> 
> 
>       How can this be Volatile?  Is there no expectation of stability
>       for the Administrator?

This should be Committed.

> 
> 
>>The following RBAC authorizations and profiles will be added.
>>
>>Authorization Names:
>>solaris.system.power.:::System Power Management::help=SystemPowerMgmt.html
>>solaris.system.power.suspend::: Suspend the System::help=Suspend.html 
>>solaris.system.power.suspend.ram::: Suspend to RAM::help=SuspendToRam.html
>>solaris.system.power.brightness::: Control LCD 
>>Brightness::help=Brightness.html
>>
>>Profiles:
>>System Power:::For authorized users to manage system power: 
>>auths=solaris.system.power;help=RtSystemPowerMngmnt.html
>>Suspend:::For authorized users to Suspend system: 
>>auths=solaris.system.power.suspend;help=RtSuspend.html
>>SuspendToRam:::For authorized users to Suspend to RAM: 
>>auths=solaris.system.power.suspend.ram;help=RtSuspendToRam.html
>>Brightness:::For authorized users to Control LCD Brightness: 
>>auths=solaris.system.power.brightness;help=RtBrightness.html
>>
>>*Will consult with the audit team to enable auditing.
> 
>       
>       IMO, this is a requirement.  See 
>       http://opnesolaris.org/os/community/arc/policies/audit-policy
>       What privileged process will be doing the audit?

hald

> 
> 
>>libpolkit interfaces
>>--------------------
>>Interface level: Volatile 
> 
>       
>       Why are these  Volatile?  If they remain Volatile, 
>       won't any consuming case need a contract?  I presume
>       LSARC/2007/702 GPM to be a consumer.  Shouldn't there
>       be a prototype contract as part of this case?

These are external interfaces that are not stable.  We will add a
contract.

> 
> 
>>The following privileges are mapped to RBAC authorizations for the solaris
>>backend.
>>
>>hal-power-suspend
>>hal-power-hibernate
>>hal-power-shutdown
>>hal-power-cpu
>>hal-power-brightness
> 
> 
>       Possibly obvious, but it would be good to define the polkit
>       to RBAC mappings and the stability of them as part of this case.

We will add the mapping to the case directory.

> 
>       I'm confused by the statement of "console owner" or RBAC auth.
>       Will libpolkit enforce this policy?  Why should it be either
>       rather than just RBAC auth?

As stated above, the Workstation Owner role is just being defined and we
did not want to depend on it.  We would like to use the role when it is
available.  If the role is not available, then there has to be a check 
for the console owner directly.

> 
>       Are there other policies implied by this case?

No

> 
> Gary..
> P.S   IIRC Randy was talikng about CLIs with me.  Is that a different
>       case?

I think it is the poweradm tool that will use these RBAC authorizations.

Phi

Reply via email to