David Chieu wrote:
> Interface            Type                    Comments
> --------------------------------------------------------------------------
> can.suspend        bool       The ability to suspend as determined
>                               by uadmin(2).

> can.hibernate      bool       The ability to hibernate as determined
>                               by uadmin(2).   

For Solaris on SPARC and x86 what are these likely to return ?

I think that on (supported) x86 systems can.suspend could return true 
because that maps to ACPI S3, but currently can.hibernate will never be 
true.  However on SPARC can.hibernate could be true but can.suspend 
would never be true.  Is that correct ?

One of the reasons I think this is very important is because of my issue 
below about the authorisations.

> More information can be found in hal-spec.html of the materials
> directory.
> 
> Brightness Ioctls
> -----------------
> Interface level: Project Private
> 
> BATT_IOC_GET_BRIGHTNESS
> BATT_IOC_SET_BRIGHTNESS
> 
> Sysevents
> ---------
> Interface level: Project Private
> 
> The EC_ACPIEV class defined in PSARC/2006/601 Battery Project will
> be extended to include the following subclasses.
> 
> ESC_ACPIEV_BRIGHTNESS_UP
> ESC_ACPIEV_BRIGHTNESS_DOWN
> ESC_ACPIEV_POWER_BUTTON
> 
> The event attributes will be the same as existing EC_ACPIEV subclasses.
> 
> Security
> --------
> Interface level: Volatile
> 
> 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

Why does suspend to RAM need its own authorisation yet hibernate does 
not, ie what is the security difference between suspended to RAM versus 
any other type of suspend ?

 > solaris.system.power.brightness::: Control LCD 
Brightness::help=Brightness.html

Is changing the brightness of the screen really security relevant such 
that it needs an authorisation and needs to be audited ?  Personally I 
don't think it is but I'd like to understand why the project team 
believes it is.

> libpolkit interfaces
> --------------------
> Interface level: Volatile 
> 
> 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

There are no such privileges in the Solaris kernel, I assume that you 
mean is the above listed HAL actions/libpolkit "privileges" require the 
previously named Solaris authorisations.


-- 
Darren J Moffat

Reply via email to