From dchieu@sac.sfbay.sun.com Mon Jan 14 15:08:30 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0EN8UF0000839 for ; Mon, 14 Jan 2008 15:08:30 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0EN8Rp2025257; Mon, 14 Jan 2008 15:08:28 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUN00M0VPM33V00@brm-avmta-1.central.sun.com>; Mon, 14 Jan 2008 16:08:27 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUN00C12PM1A4A0@brm-avmta-1.central.sun.com>; Mon, 14 Jan 2008 16:08:26 -0700 (MST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0EN8PbE044633; Mon, 14 Jan 2008 15:08:25 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0EN0qhT000615; Mon, 14 Jan 2008 15:00:52 -0800 (PST) Received: (from dchieu@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m0EN0q62000610; Mon, 14 Jan 2008 15:00:52 -0800 (PST) Date: Mon, 14 Jan 2008 15:00:52 -0800 (PST) From: David Chieu Subject: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: PSARC-ext@sun.com Cc: solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 6482 I am sponsoring this FastTrack for Phi Tran. Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GNOME Power Management Support 1.2. Name of Document Author/Supplier: Author: Phi Tran 1.3 Date of This Document: 14 January, 2008 4. Technical Description 1. Introduction 1.1. Project/Component Working Name: GNOME Power Manager Support 1.2. Name of Document Author/Supplier: Author: Phi Tran 1.3 Date of This Document: 1/10/07 4. Technical Description 4.1 Details This project enhances the battery driver (PSARC/2006/601) and HAL (PSARC/2005/399) to provide lid, brightness, power button, suspend, and hibernate support for Gnome Power Manager (LSARC/2007/702). Lid --- GPM allows the user to set actions for lid close such as suspend, hibernate, and shutdown. Suspend and hibernate actions will be 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. ACPI lid event notifications will be handled by the driver to trigger lid sysevents if the lid is closed or opened. HAL is notified by the sysevents, and GPM communicates with HAL through D-BUS. LCD Brightness Control ---------------------- There will be two methods implemented to control LCD brightness. The first way to control LCD brightness is by pressing the laptop brightness hotkeys which will generate ACPI events for brightness up or down that the battery driver will handle to change the brightness. The driver will also generate sysevents to notify HAL about the brightness change. GPM communicates with HAL through D-BUS. The second method to change brightness is through the GPM brightness applet. Support for the applet is handled through the HAL interfaces which call driver ioctls to set and get the brightness levels. In both methods, setting the brightness level will be allowed for the user who is the console owner or has the RBAC authorization. Power Button ------------ GPM allows for the configuration of power button actions such as shutdown, suspend, and hibernate. These actions will be allowed if the system supports the action, and the user is either the console owner or has the RBAC authorization. Currently, power button support is handled by the power driver and powerd. powerd polls for the button action. To enable GPM power button actions, the polling will be replaced by sysevents and HAL will handle the sysevent to notify GPM through D-BUS. powerd will no longer handle the power button press. 4.2 Interface HAL interfaces -------------- Interface level: Volatile Method Name Return Parameters Comments --------------------------------------------------------------------------- GetBrightness int status Get the current brightness. SetBrightness int level Set the current brightness. Suspend int status Put the system into ACPI S3 state. Hibernate int status Put the system into ACPI S4 state. Shutdown int status Reboot int status --------------------------------------------------------------------------- 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). button.type string Identifies buttons such as lid or power. button.has_state bool True if button maintains state, e.g. can be toggled on/off. button.state.value bool State of the button, TRUE if it is enabled. ButtonPressed string Emitted when a button is pressed such as power, lid, brightness-up, or brightness-down. laptop_panel.num_levels int The brightness levels supported by the adapter. -------------------------------------------------------------------------- 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 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. 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 4.3 References LSARC/2007/702 Gnome Power Manager PSARC/2007/679 CPUFreq HAL PSARC/2006/601 Battery Project LSARC/2006/368 D-BUS Message Bus System PSARC/2005/399 Tamarack: Removable Media Enhancements in Solaris HAL specification http://people.freedesktop.org/~david/hal-spec/hal-spec.html ACPI 3.0b http://www.acpi.info/spec.htm 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Tue Jan 15 02:00:48 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FA0lNs016113 for ; Tue, 15 Jan 2008 02:00:48 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0FA0RTN010628; Tue, 15 Jan 2008 18:00:46 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUO00A2RJT8YT00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 02:00:44 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUO009DAJT52I60@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 02:00:43 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0FA0foZ003807; Tue, 15 Jan 2008 10:00:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUO00401JEIYL00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 15 Jan 2008 10:00:41 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUO00FRIJSRIQ00@fe-emea-10.sun.com>; Tue, 15 Jan 2008 10:00:27 +0000 (GMT) Date: Tue, 15 Jan 2008 10:00:27 +0000 From: Darren J Moffat Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: David Chieu Cc: PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <478C843B.8050004@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 2644 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 From Marcel.Telka@sun.com Tue Jan 15 02:09:39 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FA9csm016426 for ; Tue, 15 Jan 2008 02:09:39 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0FA9Uue015613; Tue, 15 Jan 2008 18:09:37 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUO00801K7ZWK00@brm-avmta-1.central.sun.com>; Tue, 15 Jan 2008 03:09:35 -0700 (MST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUO008BQK7XG000@brm-avmta-1.central.sun.com>; Tue, 15 Jan 2008 03:09:34 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0FA9XgC005097; Tue, 15 Jan 2008 10:09:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUO00M01JJYCT00@fe-emea-09.sun.com> (original mail from Marcel.Telka@Sun.COM); Tue, 15 Jan 2008 10:09:33 +0000 (GMT) Received: from [129.157.71.66] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUO004L3K7KGBC0@fe-emea-09.sun.com>; Tue, 15 Jan 2008 10:09:21 +0000 (GMT) Date: Tue, 15 Jan 2008 11:09:19 +0100 From: Marcel Telka Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> Sender: Marcel.Telka@sun.com To: David Chieu Cc: PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <1200391759.8875.25.camel@tortuga> MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> Status: RO Content-Length: 7495 Hi David, please see comments inline. On Mon, 2008-01-14 at 15:00 -0800, David Chieu wrote: > I am sponsoring this FastTrack for Phi Tran. > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2008 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > GNOME Power Management Support > 1.2. Name of Document Author/Supplier: > Author: Phi Tran > 1.3 Date of This Document: > 14 January, 2008 > 4. Technical Description > 1. Introduction > 1.1. Project/Component Working Name: > GNOME Power Manager Support > 1.2. Name of Document Author/Supplier: > Author: Phi Tran > 1.3 Date of This Document: > 1/10/07 > > 4. Technical Description > 4.1 Details > This project enhances the battery driver (PSARC/2006/601) and > HAL (PSARC/2005/399) to provide lid, brightness, power button, > suspend, and hibernate support for Gnome Power Manager (LSARC/2007/702). > > Lid > --- > > GPM allows the user to set actions for lid close such as suspend, I assume that GPM is GNOME Power Manager... You used this acronym without introducing it :-). > hibernate, and shutdown. Suspend and hibernate actions will be > 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. > > ACPI lid event notifications will be handled by the driver to trigger > lid sysevents if the lid is closed or opened. HAL is notified by > the sysevents, and GPM communicates with HAL through D-BUS. > > LCD Brightness Control > ---------------------- > > There will be two methods implemented to control LCD brightness. > The first way to control LCD brightness is by pressing the laptop > brightness hotkeys which will generate ACPI events for brightness > up or down that the battery driver will handle to change the brightness. This sounds a bit strange for me. The battery driver will change LCD brightness. Why the battery driver? What is the relation between battery driver and LCD brightness? What will happen if you will run your laptop without a battery? Maybe I do not understand the battery driver concept... > The driver will also generate sysevents to notify HAL about the > brightness change. GPM communicates with HAL through D-BUS. > > The second method to change brightness is through the GPM brightness > applet. Support for the applet is handled through the HAL interfaces > which call driver ioctls to set and get the brightness levels. > > In both methods, setting the brightness level will be allowed for > the user who is the console owner or has the RBAC authorization. > > Power Button > ------------ > > GPM allows for the configuration of power button actions such as > shutdown, suspend, and hibernate. These actions will be allowed > if the system supports the action, and the user is either the console > owner or has the RBAC authorization. > > Currently, power button support is handled by the power driver and > powerd. powerd polls for the button action. To enable GPM power > button actions, the polling will be replaced by sysevents and > HAL will handle the sysevent to notify GPM through D-BUS. powerd > will no longer handle the power button press. > > 4.2 Interface > > HAL interfaces > -------------- > Interface level: Volatile > > Method Name Return Parameters Comments > --------------------------------------------------------------------------- > GetBrightness int status Get the current brightness. > SetBrightness int level Set the current brightness. > Suspend int status Put the system into ACPI S3 > state. > Hibernate int status Put the system into ACPI S4 > state. > Shutdown int status > Reboot int status > --------------------------------------------------------------------------- > > 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). > button.type string Identifies buttons such as lid or power. > button.has_state bool True if button maintains state, e.g. can be > toggled on/off. > button.state.value bool State of the button, TRUE if it is enabled. > ButtonPressed string Emitted when a button is pressed such as > power, lid, brightness-up, or brightness-down. > laptop_panel.num_levels int The brightness levels supported by the > adapter. > -------------------------------------------------------------------------- > > 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 See my previous comment above. What is the relation between brightness and battery? > > 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. Why are these events handled by battery driver? > > 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 > 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. > > 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 > > 4.3 References > LSARC/2007/702 Gnome Power Manager > PSARC/2007/679 CPUFreq HAL > PSARC/2006/601 Battery Project > LSARC/2006/368 D-BUS Message Bus System > PSARC/2005/399 Tamarack: Removable Media Enhancements in Solaris > HAL specification http://people.freedesktop.org/~david/hal-spec/hal-spec.html > ACPI 3.0b http://www.acpi.info/spec.htm > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > -- Marcel Telka Solaris RPE From randy.fishel@sun.com Tue Jan 15 09:47:58 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FHlwuM023440 for ; Tue, 15 Jan 2008 09:47:58 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0FHlvL0013235; Tue, 15 Jan 2008 09:47:58 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUP00A0T5FXBA00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 09:47:57 -0800 (PST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUP007RC5FVK110@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 09:47:56 -0800 (PST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0FHlsmq063469; Tue, 15 Jan 2008 09:47:54 -0800 (PST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id m0FHlNG7008503; Tue, 15 Jan 2008 09:47:23 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id m0FHlNrQ008499; Tue, 15 Jan 2008 09:47:23 -0800 (PST) Date: Tue, 15 Jan 2008 09:47:23 -0800 (PST) From: Randy Fishel Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <478C843B.8050004@Sun.COM> X-X-Sender: randyf@grimmy To: Darren J Moffat Cc: David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <478C843B.8050004@Sun.COM> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 3039 On Tue, 15 Jan 2008, Darren J Moffat wrote: > 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 ? "Never" is a long time, but currently can.hibernate will return true on x86 and can.suspend will return false on sparc. In this context, 'suspend' equates to entering S3, and hibernate equates to entering S4. > > One of the reasons I think this is very important is because of my issue below > about the authorisations. > > > > > 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 ? The choice here centered around the the question: Is there a reason to differentiate between auths for S3 and S4? Effectively, we believe that if a user has the privilege to do an S4, then he also has the privilege to do an S3. Partially because the state transition to S4 functionally goes to S3 first. But also because we considered the possible security considerations. In S3, system state is entirely held in RAM, and will always be contained in the running machine. If power is lost, state is lost. In S4, system state is first put to RAM (i.e. enter S3), and then written to disk, and could be saved for a long time. This image contains eveything this was contained in RAM (including the possibility decrypted data that would othewise not be on the disk) and *could* be: Viewed by someone who might get physical access to the image Copied to another machine for viewing as above Used to continue the system on a different hardware for further viewing. What we concluded from this is that it might be desireable to allow S3 and not S4, but not the opposite. This led us to the heirarcical auth: solaris.system.power.suspend == allows both S3 and S4 solaris.system.power.suspend.ram == only allows S3 Going back to the 'can.*' comments above, for a user to currently suspend a Sparc they must have solaris.system.power.suspend, and adding 'ram' would prevent the user from suspending Sparc but not x86. ---- Randy From randy.fishel@sun.com Tue Jan 15 10:03:40 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FI3eX5024131 for ; Tue, 15 Jan 2008 10:03:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0FI3dRv017498; Tue, 15 Jan 2008 10:03:40 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUP00B1B662SG00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 10:03:38 -0800 (PST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUP007G6661KG20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 10:03:37 -0800 (PST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0FI3Z8p008722; Tue, 15 Jan 2008 10:03:35 -0800 (PST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id m0FI34G7008530; Tue, 15 Jan 2008 10:03:04 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id m0FI34a5008526; Tue, 15 Jan 2008 10:03:04 -0800 (PST) Date: Tue, 15 Jan 2008 10:03:04 -0800 (PST) From: Randy Fishel Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: X-X-Sender: randyf@grimmy To: Randy Fishel Cc: Darren J Moffat , David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <478C843B.8050004@Sun.COM> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 1184 On Tue, 15 Jan 2008, Randy Fishel wrote: > > On Tue, 15 Jan 2008, Darren J Moffat wrote: > > > 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 ? > > "Never" is a long time, but currently can.hibernate will return true > on x86 and can.suspend will return false on sparc. In this context, > 'suspend' equates to entering S3, and hibernate equates to entering > S4. > Sorry, mistype. Currently: can.suspend will return true on x86 false on sparc can.hibernate will return false on x86 and true on sparc ---- Randy From Phi.Tran@sun.com Tue Jan 15 10:10:42 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FIAfCC024453 for ; Tue, 15 Jan 2008 10:10:42 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0FIAOYm016655; Tue, 15 Jan 2008 18:10:39 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUP00C1F6HPDX00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 10:10:37 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUP0074V6HOKA30@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 10:10:36 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0FIAabI020234; Tue, 15 Jan 2008 10:10:36 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUP001015YSCW00@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Tue, 15 Jan 2008 10:10:36 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUP00B756HI1ID0@fe-sfbay-10.sun.com>; Tue, 15 Jan 2008 10:10:31 -0800 (PST) Date: Tue, 15 Jan 2008 10:19:50 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: Sender: Phi.Tran@sun.com To: Randy Fishel Cc: Darren J Moffat , David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <478CF946.3040809@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <478C843B.8050004@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 3262 Randy Fishel wrote: > On Tue, 15 Jan 2008, Darren J Moffat wrote: > > >>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 ? > > > "Never" is a long time, but currently can.hibernate will return true > on x86 and can.suspend will return false on sparc. In this context, > 'suspend' equates to entering S3, and hibernate equates to entering > S4. Actually, can.suspend (ACPI S3) could be true on x86 and can.hibernate (ACPI S4) could be true on sparc. Phi > > >>One of the reasons I think this is very important is because of my issue below >>about the authorisations. >> >> >>>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 ? > > > The choice here centered around the the question: Is there a reason > to differentiate between auths for S3 and S4? > > Effectively, we believe that if a user has the privilege to do an > S4, then he also has the privilege to do an S3. Partially because the > state transition to S4 functionally goes to S3 first. But also > because we considered the possible security considerations. > > In S3, system state is entirely held in RAM, and will always be > contained in the running machine. If power is lost, state is lost. > > In S4, system state is first put to RAM (i.e. enter S3), and then > written to disk, and could be saved for a long time. This image > contains eveything this was contained in RAM (including the > possibility decrypted data that would othewise not be on the disk) and > *could* be: > > Viewed by someone who might get physical access to the image > Copied to another machine for viewing as above > Used to continue the system on a different hardware for > further viewing. > > What we concluded from this is that it might be desireable to allow > S3 and not S4, but not the opposite. This led us to the heirarcical > auth: > > solaris.system.power.suspend == allows both S3 and S4 > solaris.system.power.suspend.ram == only allows S3 > > > Going back to the 'can.*' comments above, for a user to currently > suspend a Sparc they must have solaris.system.power.suspend, and > adding 'ram' would prevent the user from suspending Sparc but not x86. > > > ---- Randy > From Phi.Tran@sun.com Tue Jan 15 10:20:55 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FIKsie024793 for ; Tue, 15 Jan 2008 10:20:54 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0FIKfiZ020248; Wed, 16 Jan 2008 02:20:52 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUP000076YPU700@nwk-avmta-2.sfbay.sun.com>; Tue, 15 Jan 2008 10:20:49 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUP00JDM6YOVG60@nwk-avmta-2.sfbay.sun.com>; Tue, 15 Jan 2008 10:20:48 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0FIKmR1004707; Tue, 15 Jan 2008 10:20:48 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUP003016KCFM00@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Tue, 15 Jan 2008 10:20:48 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUP000NC6YK5MC0@fe-sfbay-09.sun.com>; Tue, 15 Jan 2008 10:20:44 -0800 (PST) Date: Tue, 15 Jan 2008 10:30:10 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <1200391759.8875.25.camel@tortuga> Sender: Phi.Tran@sun.com To: Marcel Telka Cc: David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <478CFBB2.5050908@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <1200391759.8875.25.camel@tortuga> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 7795 Marcel Telka wrote: > Hi David, > > please see comments inline. > > On Mon, 2008-01-14 at 15:00 -0800, David Chieu wrote: > >>I am sponsoring this FastTrack for Phi Tran. >> >>Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI >>This information is Copyright 2008 Sun Microsystems >>1. Introduction >> 1.1. Project/Component Working Name: >> GNOME Power Management Support >> 1.2. Name of Document Author/Supplier: >> Author: Phi Tran >> 1.3 Date of This Document: >> 14 January, 2008 >>4. Technical Description >>1. Introduction >> 1.1. Project/Component Working Name: >> GNOME Power Manager Support >> 1.2. Name of Document Author/Supplier: >> Author: Phi Tran >> 1.3 Date of This Document: >> 1/10/07 >> >>4. Technical Description >>4.1 Details >>This project enhances the battery driver (PSARC/2006/601) and >>HAL (PSARC/2005/399) to provide lid, brightness, power button, >>suspend, and hibernate support for Gnome Power Manager (LSARC/2007/702). >> >>Lid >>--- >> >>GPM allows the user to set actions for lid close such as suspend, > > > I assume that GPM is GNOME Power Manager... > You used this acronym without introducing it :-). > > >>hibernate, and shutdown. Suspend and hibernate actions will be >>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. >> >>ACPI lid event notifications will be handled by the driver to trigger >>lid sysevents if the lid is closed or opened. HAL is notified by >>the sysevents, and GPM communicates with HAL through D-BUS. >> >>LCD Brightness Control >>---------------------- >> >>There will be two methods implemented to control LCD brightness. >>The first way to control LCD brightness is by pressing the laptop >>brightness hotkeys which will generate ACPI events for brightness >>up or down that the battery driver will handle to change the brightness. > > > This sounds a bit strange for me. The battery driver will change LCD > brightness. Why the battery driver? What is the relation between battery > driver and LCD brightness? What will happen if you will run your laptop > without a battery? Maybe I do not understand the battery driver > concept... The battery driver was first developed to handle ACPI battery events. Now support for lid and brightness ACPI events are being added to the battery driver which supports laptops. Yes, the name could probably be changed in the future. Phi > > >>The driver will also generate sysevents to notify HAL about the >>brightness change. GPM communicates with HAL through D-BUS. >> >>The second method to change brightness is through the GPM brightness >>applet. Support for the applet is handled through the HAL interfaces >>which call driver ioctls to set and get the brightness levels. >> >>In both methods, setting the brightness level will be allowed for >>the user who is the console owner or has the RBAC authorization. >> >>Power Button >>------------ >> >>GPM allows for the configuration of power button actions such as >>shutdown, suspend, and hibernate. These actions will be allowed >>if the system supports the action, and the user is either the console >>owner or has the RBAC authorization. >> >>Currently, power button support is handled by the power driver and >>powerd. powerd polls for the button action. To enable GPM power >>button actions, the polling will be replaced by sysevents and >>HAL will handle the sysevent to notify GPM through D-BUS. powerd >>will no longer handle the power button press. >> >>4.2 Interface >> >>HAL interfaces >>-------------- >>Interface level: Volatile >> >>Method Name Return Parameters Comments >>--------------------------------------------------------------------------- >>GetBrightness int status Get the current brightness. >>SetBrightness int level Set the current brightness. >>Suspend int status Put the system into ACPI S3 >> state. >>Hibernate int status Put the system into ACPI S4 >> state. >>Shutdown int status >>Reboot int status >>--------------------------------------------------------------------------- >> >>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). >>button.type string Identifies buttons such as lid or power. >>button.has_state bool True if button maintains state, e.g. can be >> toggled on/off. >>button.state.value bool State of the button, TRUE if it is enabled. >>ButtonPressed string Emitted when a button is pressed such as >> power, lid, brightness-up, or brightness-down. >>laptop_panel.num_levels int The brightness levels supported by the >> adapter. >>-------------------------------------------------------------------------- >> >>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 > > > See my previous comment above. What is the relation between brightness > and battery? > > >>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. > > > Why are these events handled by battery driver? > > >>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 >>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. >> >>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 >> >>4.3 References >>LSARC/2007/702 Gnome Power Manager >>PSARC/2007/679 CPUFreq HAL >>PSARC/2006/601 Battery Project >>LSARC/2006/368 D-BUS Message Bus System >>PSARC/2005/399 Tamarack: Removable Media Enhancements in Solaris >>HAL specification http://people.freedesktop.org/~david/hal-spec/hal-spec.html >>ACPI 3.0b http://www.acpi.info/spec.htm >> >>6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >>6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> From Phi.Tran@sun.com Tue Jan 15 10:25:39 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FIPde8024875 for ; Tue, 15 Jan 2008 10:25:39 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0FIPc27018977; Tue, 15 Jan 2008 10:25:39 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUP0000B76QVC00@brm-avmta-1.central.sun.com>; Tue, 15 Jan 2008 11:25:38 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUP00BKP76OPU90@brm-avmta-1.central.sun.com>; Tue, 15 Jan 2008 11:25:36 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0FIPaEC005395; Tue, 15 Jan 2008 10:25:36 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUP001016NX0400@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Tue, 15 Jan 2008 10:25:36 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUP0016376N9910@fe-sfbay-10.sun.com>; Tue, 15 Jan 2008 10:25:35 -0800 (PST) Date: Tue, 15 Jan 2008 10:35:01 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <478CFBB2.5050908@Sun.COM> Sender: Phi.Tran@sun.com To: Marcel Telka Cc: David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <478CFCD5.4050604@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <1200391759.8875.25.camel@tortuga> <478CFBB2.5050908@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 784 >> This sounds a bit strange for me. The battery driver will change LCD >> brightness. Why the battery driver? What is the relation between battery >> driver and LCD brightness? What will happen if you will run your laptop >> without a battery? Maybe I do not understand the battery driver >> concept... > > > The battery driver was first developed to handle ACPI battery events. > Now support for lid and brightness ACPI events are being added to the > battery driver which supports laptops. Yes, the name could probably be > changed in the future. For laptops, even if the battery is not there, the battery subsystem will be there. The battery driver has to handle events such as AC adapter when ther battery is removed and also events such as when the battery is added. Phi From gdamore@sun.com Tue Jan 15 11:27:57 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FJRuF2025578 for ; Tue, 15 Jan 2008 11:27:56 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0FJRhuo015138; Wed, 16 Jan 2008 03:27:55 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUP00J07A2GG800@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 11:27:52 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUP007CPA2GK170@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 11:27:52 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0FJRqGM015080; Tue, 15 Jan 2008 11:27:52 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUP004019UJX500@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Tue, 15 Jan 2008 11:27:52 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUP00L3PA29FT20@fe-sfbay-09.sun.com>; Tue, 15 Jan 2008 11:27:46 -0800 (PST) Date: Tue, 15 Jan 2008 11:27:36 -0800 From: "Garrett D'Amore" Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <478CFCD5.4050604@Sun.COM> Sender: Garrett.Damore@sun.com To: Phi Tran Cc: Marcel Telka , David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <478D0928.4080809@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <1200391759.8875.25.camel@tortuga> <478CFBB2.5050908@Sun.COM> <478CFCD5.4050604@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 919 A better name would be acpipower or somesuch. But that's a minor detail. -- Garrett Phi Tran wrote: > >>> This sounds a bit strange for me. The battery driver will change LCD >>> brightness. Why the battery driver? What is the relation between >>> battery >>> driver and LCD brightness? What will happen if you will run your laptop >>> without a battery? Maybe I do not understand the battery driver >>> concept... >> >> >> The battery driver was first developed to handle ACPI battery events. >> Now support for lid and brightness ACPI events are being added to the >> battery driver which supports laptops. Yes, the name could probably be >> changed in the future. > > For laptops, even if the battery is not there, the battery subsystem > will be there. The battery driver has to handle events such as AC > adapter when ther battery is removed and also events such as when the > battery is added. > > Phi From Phi.Tran@sun.com Tue Jan 15 11:34:35 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0FJYZjZ025626 for ; Tue, 15 Jan 2008 11:34:35 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0FJYVAD000634; Tue, 15 Jan 2008 12:34:34 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUP00K0BADL4H00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 11:34:33 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUP007Y2ADKKD70@nwk-avmta-1.sfbay.Sun.COM>; Tue, 15 Jan 2008 11:34:32 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0FJYWrU016175; Tue, 15 Jan 2008 11:34:32 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUP00E01A5DGV00@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Tue, 15 Jan 2008 11:34:32 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUP00L3FADC6800@fe-sfbay-09.sun.com>; Tue, 15 Jan 2008 11:34:24 -0800 (PST) Date: Tue, 15 Jan 2008 11:43:50 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <478D0928.4080809@sun.com> Sender: Phi.Tran@sun.com To: "Garrett D'Amore" Cc: Marcel Telka , David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <478D0CF6.3040707@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <1200391759.8875.25.camel@tortuga> <478CFBB2.5050908@Sun.COM> <478CFCD5.4050604@Sun.COM> <478D0928.4080809@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 1096 Garrett D'Amore wrote: > A better name would be acpipower or somesuch. But that's a minor detail. > > -- Garrett Agreed. Most likely acpi_drv since I don't want to confuse acpidrv folks who use Casper's frkit :) Phi > > Phi Tran wrote: > >> >>>> This sounds a bit strange for me. The battery driver will change LCD >>>> brightness. Why the battery driver? What is the relation between >>>> battery >>>> driver and LCD brightness? What will happen if you will run your laptop >>>> without a battery? Maybe I do not understand the battery driver >>>> concept... >>> >>> >>> >>> The battery driver was first developed to handle ACPI battery events. >>> Now support for lid and brightness ACPI events are being added to the >>> battery driver which supports laptops. Yes, the name could probably be >>> changed in the future. >> >> >> For laptops, even if the battery is not there, the battery subsystem >> will be there. The battery driver has to handle events such as AC >> adapter when ther battery is removed and also events such as when the >> battery is added. >> >> Phi > > From Vitezslav.Batrla@sun.com Wed Jan 16 00:24:43 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0G8OhNt013016 for ; Wed, 16 Jan 2008 00:24:43 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0G8OfCM039903; Wed, 16 Jan 2008 01:24:42 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUQ00909A15NQ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 16 Jan 2008 00:24:41 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUQ0062IA133S40@nwk-avmta-1.sfbay.Sun.COM>; Wed, 16 Jan 2008 00:24:41 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0G8Od7A007168; Wed, 16 Jan 2008 08:24:39 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUQ00L019T62H00@fe-emea-10.sun.com> (original mail from Vitezslav.Batrla@Sun.COM); Wed, 16 Jan 2008 08:24:39 +0000 (GMT) Received: from cml ([129.157.18.72]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUQ004TQA111TD0@fe-emea-10.sun.com>; Wed, 16 Jan 2008 08:24:38 +0000 (GMT) Date: Wed, 16 Jan 2008 09:22:24 +0100 (CET) From: Vita Batrla Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <478D0CF6.3040707@Sun.COM> Sender: Vitezslav.Batrla@sun.com X-X-Sender: vb160487@cml To: Phi Tran Cc: "Garrett D'Amore" , Marcel Telka , David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <1200391759.8875.25.camel@tortuga> <478CFBB2.5050908@Sun.COM> <478CFCD5.4050604@Sun.COM> <478D0928.4080809@sun.com> <478D0CF6.3040707@Sun.COM> Status: RO Content-Length: 1949 Another comments: - some laptops do not allow changing LCD brightness via ACPI in graphics mode (e.g. due to graphics driver). So I wonder if you could provide some command line API to do this? Gnome applet will not save a user of such laptop. - on some laptops, you need to do various tricks to read Fn key events and such laptops will likely need extra driver. How can one from this unbundled module bind keypress to e.g. change LCD brightness? Assume that there is no ACPI event for brightness up/down. Shouldn't we provide kernel API as well? Maybe it's worth considering to split ACPI functionality to several modules like: acpi_vid{eo} for switching video outputs/changing brightness acpi_bat{t} for handling battery etc.. Thanks, Vita On Tue, 15 Jan 2008, Phi Tran wrote: > Garrett D'Amore wrote: >> A better name would be acpipower or somesuch. But that's a minor detail. >> >> -- Garrett > > Agreed. Most likely acpi_drv since I don't want to confuse acpidrv folks who > use Casper's frkit :) > > Phi > >> >> Phi Tran wrote: >> >>> >>>>> This sounds a bit strange for me. The battery driver will change LCD >>>>> brightness. Why the battery driver? What is the relation between battery >>>>> driver and LCD brightness? What will happen if you will run your laptop >>>>> without a battery? Maybe I do not understand the battery driver >>>>> concept... >>>> >>>> >>>> >>>> The battery driver was first developed to handle ACPI battery events. >>>> Now support for lid and brightness ACPI events are being added to the >>>> battery driver which supports laptops. Yes, the name could probably be >>>> changed in the future. >>> >>> >>> For laptops, even if the battery is not there, the battery subsystem >>> will be there. The battery driver has to handle events such as AC >>> adapter when ther battery is removed and also events such as when the >>> battery is added. >>> >>> Phi >> >> > > From Phi.Tran@sun.com Wed Jan 16 00:49:34 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0G8nXjp013534 for ; Wed, 16 Jan 2008 00:49:33 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0G8nLj5019136; Wed, 16 Jan 2008 16:49:32 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUQ00C0BB6GDF00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 16 Jan 2008 00:49:28 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUQ00638B6F3O70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 16 Jan 2008 00:49:27 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0G8nRKj028215; Wed, 16 Jan 2008 00:49:27 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUQ00701B08A500@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Wed, 16 Jan 2008 00:49:27 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUQ00ILFB684XD0@fe-sfbay-09.sun.com>; Wed, 16 Jan 2008 00:49:27 -0800 (PST) Date: Wed, 16 Jan 2008 00:58:47 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: Sender: Phi.Tran@sun.com To: Vita Batrla Cc: "Garrett D'Amore" , Marcel Telka , David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <478DC747.9040503@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <1200391759.8875.25.camel@tortuga> <478CFBB2.5050908@Sun.COM> <478CFCD5.4050604@Sun.COM> <478D0928.4080809@sun.com> <478D0CF6.3040707@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 987 Vita Batrla wrote: > Another comments: > > - some laptops do not allow changing LCD brightness via ACPI in graphics > mode (e.g. due to graphics driver). So I wonder if you could provide > some command line API to do this? Gnome applet will not save a user of > such laptop. This case is for laptops that support ACPI methods to change brightness only. > > - on some laptops, you need to do various tricks to read Fn key events and > such laptops will likely need extra driver. How can one from this > unbundled module bind keypress to e.g. change LCD brightness? Assume > that there is no ACPI event for brightness up/down. Shouldn't we > provide kernel API as well? This support is for laptops that support ACPI hotkeys only. I'm aware of some of the issues with laptops that don't support ACPI fully and this case doesn't handle those issues. There may be future work to support laptops that don't support ACPI fully, but that will be another project. Phi From Darren.Moffat@sun.com Thu Jan 17 02:43:29 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0HAhSHQ027587 for ; Thu, 17 Jan 2008 02:43:28 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0HAhMb2014319; Thu, 17 Jan 2008 18:43:25 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUS00709B494400@brm-avmta-1.central.sun.com>; Thu, 17 Jan 2008 03:43:21 -0700 (MST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUS00104B48ZAD0@brm-avmta-1.central.sun.com>; Thu, 17 Jan 2008 03:43:21 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0HAhK5W013911; Thu, 17 Jan 2008 10:43:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUS00501B18GX00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 17 Jan 2008 10:43:20 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUS00IYLB3ZAO00@fe-emea-10.sun.com>; Thu, 17 Jan 2008 10:43:11 +0000 (GMT) Date: Thu, 17 Jan 2008 10:43:11 +0000 From: Darren J Moffat Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: Sender: Darren.Moffat@sun.com To: Randy Fishel Cc: David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <478F313F.1070202@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <478C843B.8050004@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 265 I like your rationale for why there are multiple authorisations. I'd recommend though that it be three not two, ie: solaris.system.power.suspend.disk solaris.system.power.suspend.ram Or if disk is the wrong word maybe hibernate is better. -- Darren J Moffat From randy.fishel@sun.com Thu Jan 17 10:50:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0HIoFil005272 for ; Thu, 17 Jan 2008 10:50:16 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0HIo8jX016581; Fri, 18 Jan 2008 02:50:14 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUS00L09XNPE900@brm-avmta-1.central.sun.com>; Thu, 17 Jan 2008 11:50:13 -0700 (MST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUS004M7XNNIBD0@brm-avmta-1.central.sun.com>; Thu, 17 Jan 2008 11:50:11 -0700 (MST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0HIo9cY041913; Thu, 17 Jan 2008 10:50:09 -0800 (PST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id m0HInaG7012428; Thu, 17 Jan 2008 10:49:36 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id m0HInahw012424; Thu, 17 Jan 2008 10:49:36 -0800 (PST) Date: Thu, 17 Jan 2008 10:49:36 -0800 (PST) From: Randy Fishel Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <478F313F.1070202@Sun.COM> X-X-Sender: randyf@grimmy To: Darren J Moffat Cc: Randy Fishel , David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <478C843B.8050004@Sun.COM> <478F313F.1070202@Sun.COM> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 1102 On Thu, 17 Jan 2008, Darren J Moffat wrote: > I like your rationale for why there are multiple authorisations. I'd > recommend though that it be three not two, ie: > > solaris.system.power.suspend.disk > solaris.system.power.suspend.ram We came to the proposed choice after a fair bit of discsussion around how many authorizations were "required", and it is trivial to add (now or later) the 'disk' auth. Is this a common recommendation, especially considering the 'hierarchical' nature of the actual command (disk implies ram)? > > Or if disk is the wrong word maybe hibernate is better. > This is more a terminology issue, and I am OK with 'hibernate', but whatever it is, it should be consistant: ram/disk (current proposed choice) sleep/hibernate (common "public" terminology) s3/s4 (E* 'state' terminology) The 'ram' choice (implying 'disk' if it goes that way) was choosen as a simple and descriptive set of terms that are easily understood. So unless we hear some strong alternate arguments, we will stick with the original proposal. ---- Randy From Darren.Moffat@sun.com Fri Jan 18 02:39:09 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0IAd8qe025298 for ; Fri, 18 Jan 2008 02:39:08 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0IAd12X020394; Fri, 18 Jan 2008 18:39:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUU00I075L43T00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 18 Jan 2008 02:39:04 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUU00F9L5L3A010@nwk-avmta-1.sfbay.Sun.COM>; Fri, 18 Jan 2008 02:39:04 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0IAd3t1010104; Fri, 18 Jan 2008 10:39:03 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUU000011Z4R900@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Fri, 18 Jan 2008 10:39:03 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUU0044V5KN6U10@fe-emea-10.sun.com>; Fri, 18 Jan 2008 10:38:47 +0000 (GMT) Date: Fri, 18 Jan 2008 10:38:47 +0000 From: Darren J Moffat Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: Sender: Darren.Moffat@sun.com To: Randy Fishel Cc: David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <479081B7.1020207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <478C843B.8050004@Sun.COM> <478F313F.1070202@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1649 Randy Fishel wrote: > On Thu, 17 Jan 2008, Darren J Moffat wrote: > >> I like your rationale for why there are multiple authorisations. I'd >> recommend though that it be three not two, ie: >> >> solaris.system.power.suspend.disk >> solaris.system.power.suspend.ram > > We came to the proposed choice after a fair bit of discsussion > around how many authorizations were "required", and it is trivial to > add (now or later) the 'disk' auth. Is this a common recommendation, > especially considering the 'hierarchical' nature of the actual command > (disk implies ram)? Isn't it an implementation issue though that suspend to disk first does a suspend to ram ? I think the symmetry is worth while here. >> Or if disk is the wrong word maybe hibernate is better. >> > > This is more a terminology issue, and I am OK with 'hibernate', but > whatever it is, it should be consistant: > > ram/disk (current proposed choice) That one makes most sense to me and likely to most end users. > sleep/hibernate (common "public" terminology) > s3/s4 (E* 'state' terminology) > > The 'ram' choice (implying 'disk' if it goes that way) was choosen as > a simple and descriptive set of terms that are easily understood. So > unless we hear some strong alternate arguments, we will stick with the > original proposal. I agree. s3/s4 is to arcane and IMO sleep and hibernate are too confusing due the usage in other systems. I like ram and disk - if for no other reason that it is 100% clear what is going on and it also leaves scope for suspend to some other media type :-) [ network ;-) ]. -- Darren J Moffat From Bart.Blanquart@sun.com Fri Jan 18 11:33:01 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0IJX04d004535 for ; Fri, 18 Jan 2008 11:33:01 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0IJWj6M029422; Fri, 18 Jan 2008 19:32:58 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUU00D01UAW7M00@nwk-avmta-2.sfbay.sun.com>; Fri, 18 Jan 2008 11:32:56 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUU00C8IUAVJ770@nwk-avmta-2.sfbay.sun.com>; Fri, 18 Jan 2008 11:32:56 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0IJWsVE015359; Fri, 18 Jan 2008 19:32:54 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUU00K01U60EO00@fe-emea-09.sun.com> (original mail from Bart.Blanquart@Sun.COM); Fri, 18 Jan 2008 19:32:52 +0000 (GMT) Received: from [192.168.56.101] ([81.245.24.189]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUU00KE4UARGP00@fe-emea-09.sun.com>; Fri, 18 Jan 2008 19:32:52 +0000 (GMT) Date: Fri, 18 Jan 2008 20:32:39 +0100 From: Bart Blanquart Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <479081B7.1020207@Sun.COM> Sender: Bart.Blanquart@sun.com To: Darren J Moffat Cc: Randy Fishel , David Chieu , PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.753) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801142300.m0EN0q62000610@sac.sfbay.sun.com> <478C843B.8050004@Sun.COM> <478F313F.1070202@Sun.COM> <479081B7.1020207@Sun.COM> Status: RO Content-Length: 1862 On 18 Jan 2008, at 11:38, Darren J Moffat wrote: > Randy Fishel wrote: >> On Thu, 17 Jan 2008, Darren J Moffat wrote: >>> I like your rationale for why there are multiple authorisations. >>> I'd >>> recommend though that it be three not two, ie: >>> >>> solaris.system.power.suspend.disk >>> solaris.system.power.suspend.ram >> We came to the proposed choice after a fair bit of discsussion >> around how many authorizations were "required", and it is trivial >> to add (now or later) the 'disk' auth. Is this a common >> recommendation, especially considering the 'hierarchical' nature >> of the actual command (disk implies ram)? > > Isn't it an implementation issue though that suspend to disk first > does a suspend to ram ? > I think the symmetry is worth while here. In practice I believe most people that get any of these authorisations will be given "solaris.system.power.suspend.*", though some sites may choose a more fine-grained authorisation assignment. Most of the customers that I've dealt with that are interested in finer grained controls would grant either "solaris.system.power.suspend.*" or "solaris.system.power.suspend.ram", but I can see some cases where granting "solaris.system.power.suspend.disk" but not "solaris.system.power.suspend.ram" makes sense (say, avoiding data loss in areas of rolling black outs by avoiding even accidental suspend to ram). I would expect that if a user has solaris.system.power.suspend.disk (but not solaris.system.power.suspend.ram) that that user will be able to suspend to disk only -- i.e. once the user OKs the 'hibernate' dialog the system will not stop after suspending to ram, it will write out the image to disk. The fact that it goes through the motions of a suspend to ram initially are, as Darren says, just an implementation detail. Bart From gww@eng.sun.com Sun Jan 20 12:21:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0KKL0kD001789 for ; Sun, 20 Jan 2008 12:21:00 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0KKKw3Q011218; Mon, 21 Jan 2008 04:20:59 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUY00M0DLUXQ900@brm-avmta-1.central.sun.com>; Sun, 20 Jan 2008 13:20:57 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUY009BPLUXEJ30@brm-avmta-1.central.sun.com>; Sun, 20 Jan 2008 13:20:57 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0KKKuPl024758; Sun, 20 Jan 2008 12:20:56 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m0KKJlh2009658; Sun, 20 Jan 2008 12:19:47 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0KKJlwd009657; Sun, 20 Jan 2008 12:19:47 -0800 (PST) Date: Sun, 20 Jan 2008 12:19:47 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com Cc: solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200801202019.m0KKJlwd009657@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2725 > 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? For all of these actions, what is the default value? For all of these actions, what happens if the user isn't authorized? > 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. > Security > -------- > Interface level: Volatile How can this be Volatile? Is there no expectation of stability for the Administrator? > 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? > 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? > 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. 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? Are there other policies implied by this case? Gary.. P.S IIRC Randy was talikng about CLIs with me. Is that a different case? From Irene.Huang@sun.com Sun Jan 20 21:05:21 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0L55KkE008648 for ; Sun, 20 Jan 2008 21:05:20 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0L55GrA022810; Mon, 21 Jan 2008 05:05:18 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUZ00003A4U0C00@brm-avmta-1.central.sun.com>; Sun, 20 Jan 2008 22:05:18 -0700 (MST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUZ00D63A4SGV60@brm-avmta-1.central.sun.com>; Sun, 20 Jan 2008 22:05:17 -0700 (MST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0L55FV3020655; Mon, 21 Jan 2008 05:05:15 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JUZ00K019ZI9Y00@mail-apac.sun.com> (original mail from Irene.Huang@Sun.COM); Mon, 21 Jan 2008 13:05:15 +0800 (SGT) Received: from [129.158.219.209] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JUZ00HHSA4LA175@mail-apac.sun.com>; Mon, 21 Jan 2008 13:05:11 +0800 (SGT) Date: Mon, 21 Jan 2008 13:05:22 +0800 From: Irene Huang Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200801202019.m0KKJlwd009657@marduk.eng.sun.com> Sender: Irene.Huang@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47942812.1020203@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801202019.m0KKJlwd009657@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) Status: RO Content-Length: 545 Gary Winiger wrote: >> 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 Yes, we are working on the contract. The contract will be exactly the same as http://sac.eng/Archives/CaseLog/arc/LSARC/2007/702/contracts/contract-desktop-battery.txt, which was signed by this team and JDS. --Irene From gww@eng.sun.com Sun Jan 20 21:38:33 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0L5cVVH008781 for ; Sun, 20 Jan 2008 21:38:32 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0L5cQNp015378; Mon, 21 Jan 2008 13:38:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUZ00A01BO5DD00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 20 Jan 2008 21:38:29 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUZ005IXBO5YT20@nwk-avmta-1.sfbay.Sun.COM>; Sun, 20 Jan 2008 21:38:29 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0L5cR6K030189; Sun, 20 Jan 2008 21:38:27 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m0L5bGmv010327; Sun, 20 Jan 2008 21:37:16 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0L5bGCa010326; Sun, 20 Jan 2008 21:37:16 -0800 (PST) Date: Sun, 20 Jan 2008 21:37:16 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: Irene.Huang@sun.com, gww@eng.sun.com Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200801210537.m0L5bGCa010326@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1225 > Gary Winiger wrote: > >> 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 > Yes, we are working on the contract. > The contract will be exactly the same as > http://sac.eng/Archives/CaseLog/arc/LSARC/2007/702/contracts/contract-desktop-battery.txt, > which was signed by this team and JDS. I must say that contract is not very clear. As I would say about the supplying case materials. I should have paid closer attention to the details. I'm not concerned with the HAL/DBUS stuff. I guess I'm doing that now with this case. I'm concerned with the polkit authorization interpretation and the RBAC Rights Profiles. Those are Solaris administative interfaces which I believe need a higher stablility than is afforded by Volatile. Having cross consolidation contracts for private or Volatile APIs is one thing, but saying that the authorizations and Rights Profiles names and function can change at patch boundaries concerns me. Gary.. From Irene.Huang@sun.com Sun Jan 20 21:52:12 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0L5qBWZ008950 for ; Sun, 20 Jan 2008 21:52:12 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0L5q4I3019890; Mon, 21 Jan 2008 13:52:10 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUZ00G01CAUNF00@nwk-avmta-2.sfbay.sun.com>; Sun, 20 Jan 2008 21:52:06 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUZ00D01CASEJ20@nwk-avmta-2.sfbay.sun.com>; Sun, 20 Jan 2008 21:52:06 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0L5q4Vf024315; Mon, 21 Jan 2008 05:52:04 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JUZ00H01C5SDD00@mail-apac.sun.com> (original mail from Irene.Huang@Sun.COM); Mon, 21 Jan 2008 13:52:04 +0800 (SGT) Received: from [129.158.219.209] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JUZ0030CCARMWT5@mail-apac.sun.com>; Mon, 21 Jan 2008 13:52:04 +0800 (SGT) Date: Mon, 21 Jan 2008 13:52:16 +0800 From: Irene Huang Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200801210537.m0L5bGCa010326@marduk.eng.sun.com> Sender: Irene.Huang@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47943310.20106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801210537.m0L5bGCa010326@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) Status: RO Content-Length: 1501 I see. Then we'll wait until solaris power management team decides the final stability level of libpolkit, before we continue with the contract (if needed). Regards. --Irene Gary Winiger wrote: >> Gary Winiger wrote: >> >>>> 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 >>> >> Yes, we are working on the contract. >> The contract will be exactly the same as >> http://sac.eng/Archives/CaseLog/arc/LSARC/2007/702/contracts/contract-desktop-battery.txt, >> which was signed by this team and JDS. >> > > I must say that contract is not very clear. As I would say > about the supplying case materials. I should have paid closer > attention to the details. I'm not concerned with the HAL/DBUS stuff. > I guess I'm doing that now with this case. > > I'm concerned with the polkit authorization interpretation > and the RBAC Rights Profiles. Those are Solaris administative > interfaces which I believe need a higher stablility than is > afforded by Volatile. Having cross consolidation contracts > for private or Volatile APIs is one thing, but saying that > the authorizations and Rights Profiles names and function can > change at patch boundaries concerns me. > > Gary.. > From Irene.Huang@sun.com Sun Jan 20 21:59:05 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0L5x47e009270 for ; Sun, 20 Jan 2008 21:59:04 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0L5woTr007884; Mon, 21 Jan 2008 05:59:03 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUZ00C11CMDM400@nwk-avmta-1.sfbay.Sun.COM>; Sun, 20 Jan 2008 21:59:01 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUZ005EBCMBYX40@nwk-avmta-1.sfbay.Sun.COM>; Sun, 20 Jan 2008 21:59:00 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0L5wxu7027443; Mon, 21 Jan 2008 05:58:59 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JUZ00M01CIL3J00@mail-apac.sun.com> (original mail from Irene.Huang@Sun.COM); Mon, 21 Jan 2008 13:58:59 +0800 (SGT) Received: from [129.158.219.209] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JUZ0030TCM9MWU5@mail-apac.sun.com>; Mon, 21 Jan 2008 13:58:59 +0800 (SGT) Date: Mon, 21 Jan 2008 13:59:11 +0800 From: Irene Huang Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200801210537.m0L5bGCa010326@marduk.eng.sun.com> Sender: Irene.Huang@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <479434AF.5040409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801210537.m0L5bGCa010326@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) Status: RO Content-Length: 1652 Gary Just sent the wrong link of contract, in fact, the contract about libpolkit is http://sac.eng/Archives/CaseLog/arc/LSARC/2007/702/contracts/contract-hal.txt However, Contact along is not the issue that you concern about. Let's wait for the power management team's response about the interface stability level. --Irene Gary Winiger wrote: >> Gary Winiger wrote: >> >>>> 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 >>> >> Yes, we are working on the contract. >> The contract will be exactly the same as >> http://sac.eng/Archives/CaseLog/arc/LSARC/2007/702/contracts/contract-desktop-battery.txt, >> which was signed by this team and JDS. >> > > I must say that contract is not very clear. As I would say > about the supplying case materials. I should have paid closer > attention to the details. I'm not concerned with the HAL/DBUS stuff. > I guess I'm doing that now with this case. > > I'm concerned with the polkit authorization interpretation > and the RBAC Rights Profiles. Those are Solaris administative > interfaces which I believe need a higher stablility than is > afforded by Volatile. Having cross consolidation contracts > for private or Volatile APIs is one thing, but saying that > the authorizations and Rights Profiles names and function can > change at patch boundaries concerns me. > > Gary.. > From gww@eng.sun.com Sun Jan 20 22:26:28 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0L6QS8X009737 for ; Sun, 20 Jan 2008 22:26:28 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0L6QS02019282; Sun, 20 Jan 2008 22:26:28 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUZ00F01DW4LA00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 20 Jan 2008 22:26:28 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUZ005EADW3YX60@nwk-avmta-1.sfbay.Sun.COM>; Sun, 20 Jan 2008 22:26:27 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0L6QPag040835; Sun, 20 Jan 2008 22:26:25 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m0L6PFkM010451; Sun, 20 Jan 2008 22:25:15 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0L6PFar010450; Sun, 20 Jan 2008 22:25:15 -0800 (PST) Date: Sun, 20 Jan 2008 22:25:15 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: gww@eng.sun.com, Irene.Huang@sun.com Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200801210625.m0L6PFar010450@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2355 > Just sent the wrong link of contract, in fact, the contract about > libpolkit is > http://sac.eng/Archives/CaseLog/arc/LSARC/2007/702/contracts/contract-hal.txt And I read the wrong contract. For not being clear and the case materials, I read the cpu-freq-GPM contract. IMO, it has the same flaws in specification relative to polkit, auth and profile names. I'm happy for the HAL/polkit "privileges" to be Volatile. I'm not happy to have auths and their containing profiles to be Volatile. Sorry about my getting the wrong contract. What's missing from this whole thing, I believe belongs as a case dependency of lsarc/2007/702 -- which I'll read when I get back from Holiday -- is the explicit relationship between polkit "privileges" and Solaris RBAC. Gary.. > However, Contact along is not the issue that you concern about. Let's > wait for the power management team's response about the interface > stability level. > > --Irene > Gary Winiger wrote: > >> Gary Winiger wrote: > >> > >>>> 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 > >>> > >> Yes, we are working on the contract. > >> The contract will be exactly the same as > >> http://sac.eng/Archives/CaseLog/arc/LSARC/2007/702/contracts/contract-desktop-battery.txt, > >> which was signed by this team and JDS. > >> > > > > I must say that contract is not very clear. As I would say > > about the supplying case materials. I should have paid closer > > attention to the details. I'm not concerned with the HAL/DBUS stuff. > > I guess I'm doing that now with this case. > > > > I'm concerned with the polkit authorization interpretation > > and the RBAC Rights Profiles. Those are Solaris administative > > interfaces which I believe need a higher stablility than is > > afforded by Volatile. Having cross consolidation contracts > > for private or Volatile APIs is one thing, but saying that > > the authorizations and Rights Profiles names and function can > > change at patch boundaries concerns me. > > > > Gary.. > > > > From David.Chieu@sun.com Mon Jan 21 02:28:33 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0LASWW5015996 for ; Mon, 21 Jan 2008 02:28:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0LASUiD000099; Mon, 21 Jan 2008 18:28:31 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUZ00303P3EPF00@brm-avmta-1.central.sun.com>; Mon, 21 Jan 2008 03:28:26 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUZ00DXMP3DFHD0@brm-avmta-1.central.sun.com>; Mon, 21 Jan 2008 03:28:26 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0LASPHO003762; Mon, 21 Jan 2008 02:28:25 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUZ00G01OZVPA00@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM); Mon, 21 Jan 2008 02:28:25 -0800 (PST) Received: from [129.150.16.88] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUZ004XNP3DSJ60@fe-sfbay-09.sun.com>; Mon, 21 Jan 2008 02:28:25 -0800 (PST) Date: Mon, 21 Jan 2008 02:28:25 -0800 From: David Chieu Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200801210625.m0L6PFar010450@marduk.eng.sun.com> Sender: David.Chieu@sun.com To: Gary Winiger Cc: Irene.Huang@sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <479473C9.8040601@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801210625.m0L6PFar010450@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 Status: RO Content-Length: 1175 Gary Winiger wrote: >>Just sent the wrong link of contract, in fact, the contract about >>libpolkit is >>http://sac.eng/Archives/CaseLog/arc/LSARC/2007/702/contracts/contract-hal.txt >> >> > > And I read the wrong contract. For not being clear and the case > materials, I read the cpu-freq-GPM contract. > IMO, it has the same flaws in specification relative to > polkit, auth and profile names. I'm happy for the HAL/polkit > "privileges" to be Volatile. I'm not happy to have auths > and their containing profiles to be Volatile. > Sorry about my getting the wrong contract. > > What's missing from this whole thing, I believe belongs as > a case dependency of lsarc/2007/702 -- which I'll read when > I get back from Holiday -- is the explicit relationship > between polkit "privileges" and Solaris RBAC. > >Gary.. > > For the security interface taxonomy, it sounds like we need "Private" for auths/profiles. If so, what flavor of Private? Since this runs multiple consolidations (JDS & ON), "Contracted Project Private" seems be a suitable interface classification. BTW, thanks for taking your time over the U.S. holiday to review our case. -- David Chieu From Joerg.Schilling@fokus.fraunhofer.de Tue Jan 22 08:20:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0MGKMYm010551 for ; Tue, 22 Jan 2008 08:20:23 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0MGK5Ds003748; Tue, 22 Jan 2008 16:20:19 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JV20012701S8H00@nwk-avmta-2.sfbay.sun.com>; Tue, 22 Jan 2008 08:20:16 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JV2000V801QJA10@nwk-avmta-2.sfbay.sun.com>; Tue, 22 Jan 2008 08:20:14 -0800 (PST) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0MG5aOU021014; Tue, 22 Jan 2008 16:20:14 +0000 (GMT) Received: from mms25es.sun.com ([150.143.232.94] [150.143.232.94]) by relay22i.sun.com with ESMTP id BT-MMP-1695337; Tue, 22 Jan 2008 16:20:14 +0000 (Z) Received: from relay25.sun.com (relay25.sun.com [192.12.251.14]) by mms25es.sun.com with ESMTP id BT-MMP-421147; Tue, 22 Jan 2008 16:20:13 +0000 (Z) Received: from mailgw24.noc.fraunhofer.de ([153.96.1.17] [153.96.1.17]) by relay25i.sun.com with ESMTP id BT-MMP-12955431; Tue, 22 Jan 2008 16:20:09 +0000 (Z) Received: from mailgw24.noc.fraunhofer.de (localhost [127.0.0.1]) by mailgw24.noc.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m0MGK7gL001328; Tue, 22 Jan 2008 17:20:07 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) by mailgw24.noc.fraunhofer.de (8.14.2+/8.14.2) with ESMTP id m0MEiweI009203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jan 2008 15:44:58 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.13.7/8.13.7) with SMTP id m0MEivmT018845; Tue, 22 Jan 2008 15:44:57 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jan 2008 15:44:57 +0100 Date: Tue, 22 Jan 2008 15:44:57 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <47942812.1020203@sun.com> To: Irene.Huang@sun.com, gww@eng.sun.com Cc: x86power-iteam@sun.com, tamarack-core@sun.com, solaris-battery-team@sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com Message-id: <47960169.04QHrm18Ofnq7oAb%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Fraunhofer-Email-Policy: accepted X-Antispam: No, score=-2.6/5.0, scanned in 0.074sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200801202019.m0KKJlwd009657@marduk.eng.sun.com> <47942812.1020203@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 22 Jan 2008 14:44:57.0555 (UTC) FILETIME=[5BBF6A30:01C85D05] Status: RO Content-Length: 992 Irene Huang wrote: > Gary Winiger wrote: > >> 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 > Yes, we are working on the contract. > The contract will be exactly the same as > http://sac.eng/Archives/CaseLog/arc/LSARC/2007/702/contracts/contract-desktop-battery.txt, > which was signed by this team and JDS. Please use URLs that are accessible from outside SWAN when on public mailing lists. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Phi.Tran@sun.com Tue Jan 22 11:32:17 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0MJWHcS020498 for ; Tue, 22 Jan 2008 11:32:17 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0MJWGxj015264; Tue, 22 Jan 2008 12:32:16 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JV200F098XR1X00@brm-avmta-1.central.sun.com>; Tue, 22 Jan 2008 12:32:15 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JV200CE88XPN710@brm-avmta-1.central.sun.com>; Tue, 22 Jan 2008 12:32:13 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0MJWCHK009515; Tue, 22 Jan 2008 11:32:12 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JV2004018OQ1W00@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Tue, 22 Jan 2008 11:32:12 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JV2000NR8XJRR50@fe-sfbay-09.sun.com>; Tue, 22 Jan 2008 11:32:08 -0800 (PST) Date: Tue, 22 Jan 2008 11:41:36 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200801202019.m0KKJlwd009657@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <479646F0.70801@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801202019.m0KKJlwd009657@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 3718 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 From Phi.Tran@sun.com Tue Jan 22 11:40:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0MJeIBr020796 for ; Tue, 22 Jan 2008 11:40:18 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0MJeGsZ026268; Tue, 22 Jan 2008 11:40:17 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JV20083V9B5Z300@nwk-avmta-2.sfbay.sun.com>; Tue, 22 Jan 2008 11:40:17 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JV2007PA9B25220@nwk-avmta-2.sfbay.sun.com>; Tue, 22 Jan 2008 11:40:14 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0MJeEZh010563; Tue, 22 Jan 2008 11:40:14 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JV200C017BDDT00@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Tue, 22 Jan 2008 11:40:14 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JV200KS09AT6N30@fe-sfbay-10.sun.com>; Tue, 22 Jan 2008 11:40:05 -0800 (PST) Date: Tue, 22 Jan 2008 11:49:35 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <479646F0.70801@Sun.COM> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <479648CF.3060409@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801202019.m0KKJlwd009657@marduk.eng.sun.com> <479646F0.70801@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 204 > >> 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. It's not part of this case. Phi From randyf@jurassic.eng.sun.com Tue Jan 22 15:07:57 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0MN7uGZ001244 for ; Tue, 22 Jan 2008 15:07:57 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0MN7cEl015519; Wed, 23 Jan 2008 07:07:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JV200H0JIWZKC00@nwk-avmta-2.sfbay.sun.com>; Tue, 22 Jan 2008 15:07:47 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JV2007KRIWY52B0@nwk-avmta-2.sfbay.sun.com>; Tue, 22 Jan 2008 15:07:47 -0800 (PST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id m0MN7a6J543256; Tue, 22 Jan 2008 15:07:36 -0800 (PST) Date: Tue, 22 Jan 2008 15:07:03 -0800 (PST) From: Randy Fishel Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: randy.fishel@sun.com, Darren.Moffat@sun.com Cc: dchieu@sac.sfbay.sun.com, PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Reply-to: Randy Fishel Message-id: <200801222307.m0MN7a6J543256@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2536 > > Randy Fishel wrote: > > On Thu, 17 Jan 2008, Darren J Moffat wrote: > > > >> I like your rationale for why there are multiple authorisations. I'd > >> recommend though that it be three not two, ie: > >> > >> solaris.system.power.suspend.disk > >> solaris.system.power.suspend.ram > > > > We came to the proposed choice after a fair bit of discsussion > > around how many authorizations were "required", and it is trivial to > > add (now or later) the 'disk' auth. Is this a common recommendation, > > especially considering the 'hierarchical' nature of the actual command > > (disk implies ram)? > > Isn't it an implementation issue though that suspend to disk first does > a suspend to ram ? Yes, and no. the "S" states are described as a transition, where this particular state difference nearly describes this process (go to s3, then to S4). It also happens that the implementation makes sense this way, as we step to the lowest state short of core hardware off (although "hybrid suspend" describes a nearly continual s4 transition without an s3 transition till it is time to actually make the state change). > > I think the symmetry is worth while here. Though I think one of the described use cases is more of an edge condition (not allow suspend to RAM due to unexpected power loss), the project team accepts the possibility that differentiating disk and ram is desireable, and will add solaris.system.power.suspend.disk as an authorization with the same stability of solaris.system.power.suspend.ram. ---- Randy > > >> Or if disk is the wrong word maybe hibernate is better. > >> > > > > This is more a terminology issue, and I am OK with 'hibernate', but > > whatever it is, it should be consistant: > > > > ram/disk (current proposed choice) > > That one makes most sense to me and likely to most end users. > > > sleep/hibernate (common "public" terminology) > > s3/s4 (E* 'state' terminology) > > > > The 'ram' choice (implying 'disk' if it goes that way) was choosen as > > a simple and descriptive set of terms that are easily understood. So > > unless we hear some strong alternate arguments, we will stick with the > > original proposal. > > I agree. s3/s4 is to arcane and IMO sleep and hibernate are too > confusing due the usage in other systems. I like ram and disk - if for > no other reason that it is 100% clear what is going on and it also > leaves scope for suspend to some other media type :-) [ network ;-) ]. > > > -- > Darren J Moffat From randyf@jurassic.eng.sun.com Tue Jan 22 15:19:40 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0MNJeaX001553 for ; Tue, 22 Jan 2008 15:19:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0MNJbAv014807; Tue, 22 Jan 2008 16:19:39 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JV200G1PJGPN500@nwk-avmta-1.sfbay.Sun.COM>; Tue, 22 Jan 2008 15:19:37 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.104.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JV200E1OJGOXP20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 22 Jan 2008 15:19:36 -0800 (PST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id m0MNJ5OV544401; Tue, 22 Jan 2008 15:19:06 -0800 (PST) Date: Tue, 22 Jan 2008 15:18:32 -0800 (PST) From: Randy Fishel Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: gww@eng.sun.com, Phi.Tran@sun.com Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Reply-to: Randy Fishel Message-id: <200801222319.m0MNJ5OV544401@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 532 > > > > 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 New or updated CLI's (including the soon to be 'poweradm', to which Gary and Phi refer) will be dependant on this case and will be expected to use the HAL API's defined here (or in previous HAL cases as appropriate). This case does not propose any new or updated CLI or GUI (they will, though, have a dependancy on this one). ---- Randy From David.Chieu@sun.com Wed Jan 23 01:21:36 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0N9LZgf012836 for ; Wed, 23 Jan 2008 01:21:35 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0N9LUMO022353; Wed, 23 Jan 2008 09:21:32 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JV300C03BBUTK00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Jan 2008 01:21:30 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JV3009QZBBTZK40@nwk-avmta-1.sfbay.Sun.COM>; Wed, 23 Jan 2008 01:21:29 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0N9LTh5024910; Wed, 23 Jan 2008 01:21:29 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JV300H01BAON000@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM); Wed, 23 Jan 2008 01:21:29 -0800 (PST) Received: from [129.150.16.249] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JV300FFWBBS4XD0@fe-sfbay-09.sun.com>; Wed, 23 Jan 2008 01:21:29 -0800 (PST) Date: Wed, 23 Jan 2008 01:21:28 -0800 From: David Chieu Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200801210625.m0L6PFar010450@marduk.eng.sun.com> Sender: David.Chieu@sun.com To: Gary Winiger Cc: Irene.Huang@sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com, Phi Tran , Randy Fishel Message-id: <47970718.6090808@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801210625.m0L6PFar010450@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 Status: RO Content-Length: 690 Gary, Based on your comments, the project team has an updated spec.txt (v2) at the material directory. Please see http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2008/021/material/spec_v2.txt and a diff is provided at http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2008/021/material/spec_v1_v2.diffs Additionally, there is an existing contract at http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2005/399/contract-02 The contract says: libpolkit Volatile This covers all of libpolkit interfaces, so the project team believes no new contract is needed. If there is no other comment, we believe this case should be converged. -- David Chieu From David.Chieu@sun.com Wed Jan 23 10:21:17 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0NILGpU025662 for ; Wed, 23 Jan 2008 10:21:17 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0NIL9eQ017725; Thu, 24 Jan 2008 02:21:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JV40000N0BCJJ00@nwk-avmta-2.sfbay.sun.com>; Wed, 23 Jan 2008 10:21:12 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JV400J680B685E0@nwk-avmta-2.sfbay.sun.com>; Wed, 23 Jan 2008 10:21:07 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0NIL6ag025998; Wed, 23 Jan 2008 10:21:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JV300701Z024900@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM); Wed, 23 Jan 2008 10:21:06 -0800 (PST) Received: from [10.1.48.114] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JV4005HP0AY6R00@fe-sfbay-10.sun.com>; Wed, 23 Jan 2008 10:20:58 -0800 (PST) Date: Wed, 23 Jan 2008 10:21:24 -0800 From: David Chieu Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] In-reply-to: <47970718.6090808@sun.com> Sender: David.Chieu@sun.com To: David Chieu Cc: Gary Winiger , Irene.Huang@sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com, Phi Tran , Randy Fishel Message-id: <479785A4.8000509@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801210625.m0L6PFar010450@marduk.eng.sun.com> <47970718.6090808@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 931 I may have jumped the gun on this. Per this morning's PSARC meeting, Gary has not yet finished reviewing the updated spec. So, extending the timer to 1/30/2008. -- David Chieu David Chieu wrote: > Gary, > > Based on your comments, the project team has an updated spec.txt (v2) > at the material directory. Please see > http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2008/021/material/spec_v2.txt > > and a diff is provided at > http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2008/021/material/spec_v1_v2.diffs > > > Additionally, there is an existing contract at > http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2005/399/contract-02 > > The contract says: > libpolkit Volatile > > This covers all of libpolkit interfaces, so the project team believes > no new contract is needed. > > If there is no other comment, we believe this case should be converged. > > -- David Chieu > From gww@eng.sun.com Sun Jan 27 17:52:29 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0S1qTDj029391 for ; Sun, 27 Jan 2008 17:52:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0S1qSxS000984; Sun, 27 Jan 2008 18:52:28 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVB00301ZVGNI00@brm-avmta-1.central.sun.com>; Sun, 27 Jan 2008 18:52:28 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVB00J92ZVFJN30@brm-avmta-1.central.sun.com>; Sun, 27 Jan 2008 18:52:27 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0S1qQh8022122; Sun, 27 Jan 2008 17:52:26 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m0S1p8PY027992; Sun, 27 Jan 2008 17:51:08 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0S1p84Y027991; Sun, 27 Jan 2008 17:51:08 -0800 (PST) Date: Sun, 27 Jan 2008 17:51:08 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: Phi.Tran@sun.com, gww@eng.sun.com Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200801280151.m0S1p84Y027991@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 489 > > 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. Nit: It is not a "Role", it is a "Rights Profile". Gary.. From gww@eng.sun.com Sun Jan 27 17:53:07 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0S1r77f029405 for ; Sun, 27 Jan 2008 17:53:07 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0S1r0BS028726; Mon, 28 Jan 2008 01:53:06 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVB00305ZWFO800@brm-avmta-1.central.sun.com>; Sun, 27 Jan 2008 18:53:03 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVB00JZ1ZWEJM20@brm-avmta-1.central.sun.com>; Sun, 27 Jan 2008 18:53:02 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0S1r09L022217; Sun, 27 Jan 2008 17:53:00 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m0S1pg74028020; Sun, 27 Jan 2008 17:51:42 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0S1pgDk028019; Sun, 27 Jan 2008 17:51:42 -0800 (PST) Date: Sun, 27 Jan 2008 17:51:42 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] To: David.Chieu@sun.com Cc: Irene.Huang@sun.com, PSARC-ext@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, gww@eng.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200801280151.m0S1pgDk028019@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1675 David, > I may have jumped the gun on this. Per this morning's PSARC meeting, > Gary has not yet finished reviewing the updated spec. So, extending the > timer to 1/30/2008. Thanks. > > Based on your comments, the project team has an updated spec.txt (v2) > > at the material directory. Please see > > http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2008/021/material/spec_v2.txt I don't see the default values discussed in the updated spec. IMO, these seem important to the user experience and relevant to the case. When Solaris first installed, what will occur if the Lid is closed, what is the LCD brightness, what action does the power button have? Perhaps parochically, I also don't see why the policy, which I believe is implemented in HAL, should not just depend on PSARC/2008/034 Defining Workstation Owner Infrastructure. And thus this case have a dependency to that one. Afterall, this/that is exactly why 2008/034 was submitted. It seems to me implementing your own /dev/console and authorization tests side step the architecuture of allowing the Administrator to have control. Finally perhaps a wording nit: "*Will consult with the audit team to enable auditing." seems somewhat weak. Will meet the Solaris Audit policy, http://opensolaris.org/os/community/arc/policies/audit-policy seem more appropriate. Gary.. P.S. The schedule of 2008/034 is not architecturally relevant. Feel free to add yourself to the interest list of 6650907 Implement PSARC/2008/034 Defining Workstation Owner Infrastructure and have management escalate if you find the resourcing and timing in conflict with other escalated project issues. From gww@eng.sun.com Sun Jan 27 18:29:18 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0S2THDe029848 for ; Sun, 27 Jan 2008 18:29:18 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0S2TCKG011398; Mon, 28 Jan 2008 10:29:16 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVC00A031KQOF00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 27 Jan 2008 18:29:14 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVC00B4F1KPKC80@nwk-avmta-1.sfbay.Sun.COM>; Sun, 27 Jan 2008 18:29:14 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0S2TCZl029374; Sun, 27 Jan 2008 18:29:12 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m0S2RrZl028058; Sun, 27 Jan 2008 18:27:53 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0S2RrwO028057; Sun, 27 Jan 2008 18:27:53 -0800 (PST) Date: Sun, 27 Jan 2008 18:27:53 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] To: David.Chieu@sun.com Cc: Irene.Huang@sun.com, PSARC-ext@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, gww@eng.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200801280227.m0S2RrwO028057@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1309 > > Additionally, there is an existing contract at > > http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2005/399/contract-02 > > > > The contract says: > > libpolkit Volatile > > > > This covers all of libpolkit interfaces, so the project team believes > > no new contract is needed. And that contract is between the SUPPLIER solaris/volmgt/utility and CONSUMER jds/gnome/file-manager, jds/gnome/applications it is also incorrectly (and poorly) specifies the use of authorizations not polkit "privileges" What does this case deal with? Volume management authorizations? What does the LSARC dependent case consume? Volume management authorizations? The point is that this case is exporting polkit "privileges" as volatile and it is not the Bugster solaris/volmgt/utility and the consuming case is not importing the HAL volume management authorizations. And this whole thing is cross consolidation. This is exactly what contracts are designed for. If someone wishes to run a separate libpolkit case which SUPPLIES all the "privileges" and contracts to each CONSUMER, that would be fine. It just seems to me that the ARC rules call for a contract which SUPPLIES the "privileges" consumed to jds/gnome/??? and that isn't the existant contract. Gary.. From Phi.Tran@sun.com Sun Jan 27 21:19:55 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0S5JtIk001977 for ; Sun, 27 Jan 2008 21:19:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0S5Jsde004474; Sun, 27 Jan 2008 21:19:54 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVC00K019H6B100@brm-avmta-1.central.sun.com>; Sun, 27 Jan 2008 22:19:54 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVC00JH59H5JUD0@brm-avmta-1.central.sun.com>; Sun, 27 Jan 2008 22:19:53 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0S5JrUm022526; Sun, 27 Jan 2008 21:19:53 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVC00F019B1EX00@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Sun, 27 Jan 2008 21:19:53 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVC00D899H45S10@fe-sfbay-09.sun.com>; Sun, 27 Jan 2008 21:19:53 -0800 (PST) Date: Sun, 27 Jan 2008 21:29:23 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] In-reply-to: <200801280151.m0S1pgDk028019@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, Irene.Huang@sun.com, PSARC-ext@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <479D6833.4040202@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801280151.m0S1pgDk028019@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 2334 Gary Winiger wrote: > David, > > >>I may have jumped the gun on this. Per this morning's PSARC meeting, >>Gary has not yet finished reviewing the updated spec. So, extending the >>timer to 1/30/2008. > > > Thanks. > > >>>Based on your comments, the project team has an updated spec.txt (v2) >>>at the material directory. Please see >>>http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2008/021/material/spec_v2.txt > > > I don't see the default values discussed in the updated > spec. IMO, these seem important to the user experience > and relevant to the case. When Solaris first installed, > what will occur if the Lid is closed, what is the LCD brightness, > what action does the power button have? The LSARC GPM case handles the GUI which really sets the default action. Lid -- the default action on lid close is to do nothing. Power button -- the default action is to ask the user similiar to what happens now. It will display gnome-sys-suspend GUI when the power button is pressed. Brightness -- Nothing will happen, i.e. no change in brightness. > > Perhaps parochically, I also don't see why the policy, which I > believe is implemented in HAL, should not just depend on PSARC/2008/034 > Defining Workstation Owner Infrastructure. And thus this > case have a dependency to that one. Afterall, this/that is > exactly why 2008/034 was submitted. It seems to me implementing > your own /dev/console and authorization tests side step the > architecuture of allowing the Administrator to have control. > > Finally perhaps a wording nit: "*Will consult with the audit > team to enable auditing." seems somewhat weak. Will meet > the Solaris Audit policy, > http://opensolaris.org/os/community/arc/policies/audit-policy > seem more appropriate. Ok, I will change the wording. > > Gary.. > P.S. The schedule of 2008/034 is not architecturally relevant. > Feel free to add yourself to the interest list of > 6650907 Implement PSARC/2008/034 Defining Workstation Owner Infrastructure > and have management escalate if you find the resourcing and > timing in conflict with other escalated project issues. > When this project was started, PSARC/2008/034 Defining Workstation Owner Infrastructure wasn't on the horizon at all. I'll contact you separately about your case plans. Phi From Phi.Tran@sun.com Sun Jan 27 21:20:33 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0S5KWb1001991 for ; Sun, 27 Jan 2008 21:20:32 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0S5KSDm028172; Mon, 28 Jan 2008 05:20:29 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVC005019I4AQ00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 27 Jan 2008 21:20:28 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVC0032M9I3PU10@nwk-avmta-1.sfbay.Sun.COM>; Sun, 27 Jan 2008 21:20:27 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0S5KR4W022577; Sun, 27 Jan 2008 21:20:27 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVC00I01994VS00@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Sun, 27 Jan 2008 21:20:27 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVC00HPP9I2YAC0@fe-sfbay-10.sun.com>; Sun, 27 Jan 2008 21:20:27 -0800 (PST) Date: Sun, 27 Jan 2008 21:29:58 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] In-reply-to: <200801280227.m0S2RrwO028057@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, Irene.Huang@sun.com, PSARC-ext@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <479D6856.2020601@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801280227.m0S2RrwO028057@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 1812 Gary Winiger wrote: >>>Additionally, there is an existing contract at >>>http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2005/399/contract-02 >>> >>>The contract says: >>>libpolkit Volatile >>> >>>This covers all of libpolkit interfaces, so the project team believes >>>no new contract is needed. > > > And that contract is between the SUPPLIER solaris/volmgt/utility > and CONSUMER jds/gnome/file-manager, jds/gnome/applications > it is also incorrectly (and poorly) specifies the use of > authorizations not polkit "privileges" > What does this case deal with? Volume management authorizations? > What does the LSARC dependent case consume? Volume management > authorizations? libpolkit is part of category solaris/library/libpolkit, but the category wasn't noted. > > The point is that this case is exporting polkit "privileges" > as volatile and it is not the Bugster solaris/volmgt/utility > and the consuming case is not importing the HAL volume management > authorizations. And this whole thing is cross consolidation. > This is exactly what contracts are designed for. > > If someone wishes to run a separate libpolkit case which > SUPPLIES all the "privileges" and contracts to each CONSUMER, > that would be fine. > > It just seems to me that the ARC rules call for a contract > which SUPPLIES the "privileges" consumed to jds/gnome/??? > and that isn't the existant contract. The libpolkit "privileges" are part of the libpolkit interfaces. I thought this contract did intend to cover solaris/library/libpolkit even if that category was missing since the interface noted libpolkit. To clarify the contract, we will work with the interface consumer to make a new contract which will note the solaris/library/libpolkit category. Phi From randy.fishel@sun.com Mon Jan 28 13:21:33 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0SLLWd1022374 for ; Mon, 28 Jan 2008 13:21:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0SLLQ9X026837; Tue, 29 Jan 2008 05:21:31 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVD00807HZTSI00@brm-avmta-1.central.sun.com>; Mon, 28 Jan 2008 14:21:29 -0700 (MST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVD00J0GHZT8K80@brm-avmta-1.central.sun.com>; Mon, 28 Jan 2008 14:21:29 -0700 (MST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0SLLQlL059724; Mon, 28 Jan 2008 13:21:26 -0800 (PST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id m0SLKnG7028066; Mon, 28 Jan 2008 13:20:49 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id m0SLKnLk028062; Mon, 28 Jan 2008 13:20:49 -0800 (PST) Date: Mon, 28 Jan 2008 13:20:49 -0800 (PST) From: Randy Fishel Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] In-reply-to: <200801280151.m0S1pgDk028019@marduk.eng.sun.com> X-X-Sender: randyf@grimmy To: Gary Winiger Cc: David.Chieu@sun.com, Irene.Huang@sun.com, PSARC-ext@sun.com, Phi.Tran@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801280151.m0S1pgDk028019@marduk.eng.sun.com> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 2234 On Sun, 27 Jan 2008, Gary Winiger wrote: > > > > Based on your comments, the project team has an updated spec.txt (v2) > > > at the material directory. Please see > > > http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2008/021/material/spec_v2.txt > > I don't see the default values discussed in the updated > spec. IMO, these seem important to the user experience > and relevant to the case. When Solaris first installed, > what will occur if the Lid is closed, what is the LCD brightness, > what action does the power button have? I think you have your cases mixed up. This case doesn't define any defaults, but implements requests: i.e. "Can the user suspend, if yes, suspend, if not fail". What the "defaults" are (or maybe "install defaults") would be part of a tool (such as GNOME Power Manager LSARC/2007/702) that would use these interfaces. And even if the installed default for that tool indicates a suspend on lid close, if the user doesn't have the authorization to suspend, the machine won't. > > Perhaps parochically, I also don't see why the policy, which I > believe is implemented in HAL, should not just depend on PSARC/2008/034 > Defining Workstation Owner Infrastructure. And thus this > case have a dependency to that one. Afterall, this/that is > exactly why 2008/034 was submitted. It seems to me implementing > your own /dev/console and authorization tests side step the > architecuture of allowing the Administrator to have control. This case doesn't intend to implement /dev/console tests and will use chkauthattr() with the auths specified in this case to determine if a user has the appropriate authorizations. It is mostly a courtesy that it references any future "console" related tests or cases, and (IMHO) doesn't directly care about PSARC/2008/034 (though that case is probably more dependant on this one as it is trying to define the what the rights of a "Workstation Owner" are, and I suspect that the power profiles defined here should be included). If the code for PSARC/2008/034 exists, then the user will be able to get permissions just by logging into the console, if it doesn't then they will need to be explicitly entered. ---- Randy From gww@eng.sun.com Mon Jan 28 17:41:44 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0T1fhc2001023 for ; Mon, 28 Jan 2008 17:41:44 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0T1fYP6002626; Tue, 29 Jan 2008 01:41:42 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVD00M01U1G5700@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Jan 2008 17:41:40 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVD00CL6U1FJM70@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Jan 2008 17:41:40 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0T1fbcT011148; Mon, 28 Jan 2008 17:41:37 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m0T1eHdp029904; Mon, 28 Jan 2008 17:40:17 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0T1eHxG029903; Mon, 28 Jan 2008 17:40:17 -0800 (PST) Date: Mon, 28 Jan 2008 17:40:17 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] To: Phi.Tran@sun.com, gww@eng.sun.com Cc: David.Chieu@sun.com, Irene.Huang@sun.com, PSARC-ext@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200801290140.m0T1eHxG029903@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3634 > > I don't see the default values discussed in the updated > > spec. IMO, these seem important to the user experience > > and relevant to the case. When Solaris first installed, > > what will occur if the Lid is closed, what is the LCD brightness, > > what action does the power button have? > > The LSARC GPM case handles the GUI which really sets the default action. From my comments there: "the PSARC GPM case is implying that the LSARC GPM [2007/702] case is to specify the the default values for lid, brightness, power and by implication CPUFreq. IMO, that is backwards, and still needs to be worked out." They are not specified there. Indeed IMO, that is backwards. The LSARC case has no privilege to set anything. How can it define defaults? IMO, one of the things this case needs to do is provide the defaults for a freshly installed system. I'd expect it to be this case. > Lid -- the default action on lid close is to do nothing. > Power button -- the default action is to ask the user similiar to what > happens now. It will display gnome-sys-suspend GUI when the power > button is pressed. > Brightness -- Nothing will happen, i.e. no change in brightness. Are these the specified defaults for what this case will supply? Now on to a real question with Lid: The actions from the LSARC GPM case says: "such as blank screen,suspend,hibernate,shutdown. Suspend and hibernate depends on HAL interfaces, particularly blanking screen relies on X11 extension DPMS." I don't see blank screen in the spec of this case. And most importantly, it would seem to me that entering screen lock would be a required action in the set of selectable actions -- and from a security perspective the default. It certainly is a selectable option on MacOS: "Require password to wake this computer from sleep or screen saver" is what it is called. How does this case provide for a screen lock on lid switching? > > Perhaps parochically, I also don't see why the policy, which I > > believe is implemented in HAL, should not just depend on PSARC/2008/034 > > Defining Workstation Owner Infrastructure. And thus this > > case have a dependency to that one. Afterall, this/that is > > exactly why 2008/034 was submitted. It seems to me implementing > > your own /dev/console and authorization tests side step the > > architecuture of allowing the Administrator to have control. [relocated -- really not architectural] > When this project was started, PSARC/2008/034 Defining Workstation Owner > Infrastructure wasn't on the horizon at all. I won't argue timing with you. It's been on the horizon for quite some time (years infact) and under active discussion including Randy and the x86power team in my mail log since 11 Dec. Indeed this was one of the motivating cases for not delaying the work any longer. > I'll contact you separately about your case plans. My plan is to do the work as it fits with the other things I've been tasked to do. IMO, your plan needs to be dependent on that work. As I said, if your management doesn't like the pace at which I'm able to deliver, they can provide resources and/or discuss other options with my management. > > Finally perhaps a wording nit: "*Will consult with the audit > > team to enable auditing." seems somewhat weak. Will meet > > the Solaris Audit policy, > > http://opensolaris.org/os/community/arc/policies/audit-policy > > seem more appropriate. > > Ok, I will change the wording. So you'll be meeting with the Audit project team sometime soon ;-) and wanting input/resources from them (i.e., me). Gary.. From Phi.Tran@sun.com Mon Jan 28 17:54:52 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0T1sph8001572 for ; Mon, 28 Jan 2008 17:54:51 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0T1seLF022117; Tue, 29 Jan 2008 09:54:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVD0070XUN8SU00@nwk-avmta-2.sfbay.sun.com>; Mon, 28 Jan 2008 17:54:44 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVD00DS0UN7D4D0@nwk-avmta-2.sfbay.sun.com>; Mon, 28 Jan 2008 17:54:43 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0T1shYt011045; Mon, 28 Jan 2008 17:54:43 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVD00L01UGBWP00@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Mon, 28 Jan 2008 17:54:43 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVD007RLUN6JGF0@fe-sfbay-09.sun.com>; Mon, 28 Jan 2008 17:54:43 -0800 (PST) Date: Mon, 28 Jan 2008 18:04:15 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] In-reply-to: <200801290140.m0T1eHxG029903@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, Irene.Huang@sun.com, PSARC-ext@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <479E899F.6050707@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801290140.m0T1eHxG029903@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 4417 Gary Winiger wrote: >>> I don't see the default values discussed in the updated >>> spec. IMO, these seem important to the user experience >>> and relevant to the case. When Solaris first installed, >>> what will occur if the Lid is closed, what is the LCD brightness, >>> what action does the power button have? >> >>The LSARC GPM case handles the GUI which really sets the default action. > > > From my comments there: "the PSARC GPM case is implying that the > LSARC GPM [2007/702] case is to specify the the default values > for lid, brightness, power and by implication CPUFreq. > IMO, that is backwards, and still needs to be worked out." The PSARC case does not imply it will set the defaults on a freshly installed system. My comments above means exactly that the GPM GUI which is handled by the LSARC case will set the defaults. > > They are not specified there. Indeed IMO, that is backwards. > The LSARC case has no privilege to set anything. How can it > define defaults? The LSARC case need privileges to do something like "nothing" when the lid closes or do nothing for brightness? IMO, one of the things this case needs to > do is provide the defaults for a freshly installed system. > I'd expect it to be this case. > See above. > >>Lid -- the default action on lid close is to do nothing. >>Power button -- the default action is to ask the user similiar to what >>happens now. It will display gnome-sys-suspend GUI when the power >>button is pressed. >>Brightness -- Nothing will happen, i.e. no change in brightness. > > > Are these the specified defaults for what this case will > supply? No. I was just answering your question for your information. These defaults are not handled by this case. > > Now on to a real question with Lid: The actions from the > LSARC GPM case says: "such as blank screen,suspend,hibernate,shutdown. > Suspend and hibernate depends on HAL interfaces, particularly > blanking screen relies on X11 extension DPMS." > I don't see blank screen in the spec of this case. The GPM GUI does the calls into DPMS. It doesn't rely on this case. > > And most importantly, it would seem to me that entering > screen lock would be a required action in the set of selectable > actions -- and from a security perspective the default. > It certainly is a selectable option on MacOS: > "Require password to wake this computer from sleep or screen > saver" is what it is called. Screen locking is not required. What policy are you referencing that makes it a requirement? > > How does this case provide for a screen lock on lid switching? > > >>> Perhaps parochically, I also don't see why the policy, which I >>> believe is implemented in HAL, should not just depend on PSARC/2008/034 >>> Defining Workstation Owner Infrastructure. And thus this >>> case have a dependency to that one. Afterall, this/that is >>> exactly why 2008/034 was submitted. It seems to me implementing >>> your own /dev/console and authorization tests side step the >>> architecuture of allowing the Administrator to have control. > > > [relocated -- really not architectural] > >>When this project was started, PSARC/2008/034 Defining Workstation Owner >>Infrastructure wasn't on the horizon at all. > > > I won't argue timing with you. It's been on the horizon for > quite some time (years infact) and under active discussion > including Randy and the x86power team in my mail log since 11 Dec. > Indeed this was one of the motivating cases for not delaying the > work any longer. I meant concrete stuff, not talk. Phi > > >>I'll contact you separately about your case plans. > > > My plan is to do the work as it fits with the other things > I've been tasked to do. IMO, your plan needs to be dependent > on that work. As I said, if your management doesn't like the > pace at which I'm able to deliver, they can provide resources > and/or discuss other options with my management. > > >>> Finally perhaps a wording nit: "*Will consult with the audit >>> team to enable auditing." seems somewhat weak. Will meet >>> the Solaris Audit policy, >>> http://opensolaris.org/os/community/arc/policies/audit-policy >>> seem more appropriate. >> >>Ok, I will change the wording. > > > So you'll be meeting with the Audit project team sometime > soon ;-) and wanting input/resources from them (i.e., me). > > Gary.. From gww@eng.sun.com Mon Jan 28 17:54:54 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0T1sqNU001576 for ; Mon, 28 Jan 2008 17:54:53 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m0T1sjYX022133; Tue, 29 Jan 2008 09:54:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVD00009UNDDF00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Jan 2008 17:54:49 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVD00C93UNBJJ90@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Jan 2008 17:54:47 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0T1siUH015744; Mon, 28 Jan 2008 17:54:44 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m0T1rO6x029923; Mon, 28 Jan 2008 17:53:24 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0T1rO4r029922; Mon, 28 Jan 2008 17:53:24 -0800 (PST) Date: Mon, 28 Jan 2008 17:53:24 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] To: gww@eng.sun.com, randy.fishel@sun.com Cc: David.Chieu@sun.com, Irene.Huang@sun.com, PSARC-ext@sun.com, Phi.Tran@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200801290153.m0T1rO4r029922@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2973 > > > > Based on your comments, the project team has an updated spec.txt (v2) > > > > at the material directory. Please see > > > > http://sac.eng.sun.com/Archives/CaseLog/arc/PSARC/2008/021/material/spec_v2.txt > > > > I don't see the default values discussed in the updated > > spec. IMO, these seem important to the user experience > > and relevant to the case. When Solaris first installed, > > what will occur if the Lid is closed, what is the LCD brightness, > > what action does the power button have? > > I think you have your cases mixed up. This case doesn't define any > defaults, but implements requests: i.e. "Can the user suspend, if yes, > suspend, if not fail". What the "defaults" are (or maybe "install > defaults") would be part of a tool (such as GNOME Power Manager > LSARC/2007/702) that would use these interfaces. And even if the > installed default for that tool indicates a suspend on lid close, if > the user doesn't have the authorization to suspend, the machine won't. I guess I still miss seeing the big picture I've asked for (at least at LSARC). This seems to be playing he said she said. So, just what useful will be delivered to the customer/user of all this stuff? > > Perhaps parochically, I also don't see why the policy, which I > > believe is implemented in HAL, should not just depend on PSARC/2008/034 > > Defining Workstation Owner Infrastructure. And thus this > > case have a dependency to that one. Afterall, this/that is > > exactly why 2008/034 was submitted. It seems to me implementing > > your own /dev/console and authorization tests side step the > > architecuture of allowing the Administrator to have control. > > This case doesn't intend to implement /dev/console tests and will > use chkauthattr() with the auths specified in this case to determine > if a user has the appropriate authorizations. It is mostly a courtesy > that it references any future "console" related tests or cases, and > (IMHO) doesn't directly care about PSARC/2008/034 (though that case is > probably more dependant on this one as it is trying to define the what > the rights of a "Workstation Owner" are, and I suspect that the power > profiles defined here should be included). If the code for > PSARC/2008/034 exists, then the user will be able to get permissions > just by logging into the console, if it doesn't then they will need to > be explicitly entered. So before I disagree, where is the customer/admin docs that will be supplied to tell how to use this? Where is the administrative interface? I guess we can just ship another erector set with no instructions and missing parts and let the end user/admin try to figure it all out. Sigh, IMO that is totally broken from an ease of use and KISS perspective. So, I'd disagree architecturally part of this case should be to deliver rights profiles into the PSARC/2008/034 "Workstation Owner" Rights Profile. Gary.. From Phi.Tran@sun.com Mon Jan 28 22:14:59 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0T6ExFI006096 for ; Mon, 28 Jan 2008 22:14:59 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0T6ErEe028998; Tue, 29 Jan 2008 06:14:56 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVE00A096OSBS00@brm-avmta-1.central.sun.com>; Mon, 28 Jan 2008 23:14:53 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVE00L5O6ORBU40@brm-avmta-1.central.sun.com>; Mon, 28 Jan 2008 23:14:51 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0T6EpuJ009965; Mon, 28 Jan 2008 22:14:51 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVE00J016KQMW00@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Mon, 28 Jan 2008 22:14:51 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVE000RC6OQOPA0@fe-sfbay-10.sun.com>; Mon, 28 Jan 2008 22:14:50 -0800 (PST) Date: Mon, 28 Jan 2008 22:24:23 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] In-reply-to: <479E899F.6050707@Sun.COM> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, Irene.Huang@sun.com, PSARC-ext@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <479EC697.9090609@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801290140.m0T1eHxG029903@marduk.eng.sun.com> <479E899F.6050707@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 831 >> And most importantly, it would seem to me that entering >> screen lock would be a required action in the set of selectable >> actions -- and from a security perspective the default. >> It certainly is a selectable option on MacOS: >> "Require password to wake this computer from sleep or screen >> saver" is what it is called. > > > Screen locking is not required. What policy are you referencing that > makes it a requirement? I thought you meant a separate action, but if you mean GPM must lock the screen before sleeping, etc., then yes, that will happen. > >> >> How does this case provide for a screen lock on lid switching? >> This PSARC case doesn't directly handle the screen locking, but GPM will call the xscreensaver-command before the actions such as suspend or blank screen. Phi From sacadmin Mon Jan 28 23:27:36 2008 Received: from marduk.eng.sun.com (marduk [129.146.108.224]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0T7Ra7K007222 for ; Mon, 28 Jan 2008 23:27:36 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m0T7QG1B001550; Mon, 28 Jan 2008 23:26:16 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m0T7QGoI001549; Mon, 28 Jan 2008 23:26:16 -0800 (PST) Date: Mon, 28 Jan 2008 23:26:16 -0800 (PST) From: Gary Winiger Message-Id: <200801290726.m0T7QGoI001549@marduk.eng.sun.com> To: gww@eng.sun.com, Phi.Tran@sun.com Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] 2007/702 Cc: David.Chieu@sun.com, Irene.Huang@sun.com, PSARC-ext@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com, lsarc@sac.sfbay.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1165 Phi, > >> And most importantly, it would seem to me that entering > >> screen lock would be a required action in the set of selectable > >> actions -- and from a security perspective the default. > >> It certainly is a selectable option on MacOS: > >> "Require password to wake this computer from sleep or screen > >> saver" is what it is called. > > > > > > Screen locking is not required. What policy are you referencing that > > makes it a requirement? > > I thought you meant a separate action, but if you mean GPM must lock the > screen before sleeping, etc., then yes, that will happen. I'm not concerned that it be a separate GPM (either PSARC or LSARC case) action, but that it be supportable during such things as lid close/sleep/hibernate. > >> How does this case provide for a screen lock on lid switching? > >> > > This PSARC case doesn't directly handle the screen locking, but GPM > will call the xscreensaver-command before the actions such as suspend > or blank screen. Too many GPMs, I presume you mean LSARC 2007/702 GPM. It would be really good to have it specify its architectural operations. Gary.. From sacadmin Mon Jan 28 23:49:21 2008 Received: from dm-eng-02.sfbay.sun.com (dm-eng-02 [129.146.11.32]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0T7nLVg007311 for ; Mon, 28 Jan 2008 23:49:21 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0T7nLOn005945 for ; Mon, 28 Jan 2008 23:49:21 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0T7nGps020721 for ; Mon, 28 Jan 2008 23:49:16 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVE00C01AYLLG00@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM) for lsarc@sac.eng.sun.com; Mon, 28 Jan 2008 23:49:16 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVE00M54B23QOC0@fe-sfbay-09.sun.com>; Mon, 28 Jan 2008 23:49:16 -0800 (PST) Date: Mon, 28 Jan 2008 23:58:48 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] 2007/702 In-reply-to: <200801290726.m0T7QGoI001549@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, Irene.Huang@sun.com, PSARC-ext@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com, lsarc@sac.sfbay.sun.com Message-id: <479EDCB8.7030104@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200801290726.m0T7QGoI001549@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 1424 Gary Winiger wrote: > Phi, > > >>>> And most importantly, it would seem to me that entering >>>> screen lock would be a required action in the set of selectable >>>> actions -- and from a security perspective the default. >>>> It certainly is a selectable option on MacOS: >>>> "Require password to wake this computer from sleep or screen >>>> saver" is what it is called. >>> >>> >>>Screen locking is not required. What policy are you referencing that >>>makes it a requirement? >> >>I thought you meant a separate action, but if you mean GPM must lock the >>screen before sleeping, etc., then yes, that will happen. > > > I'm not concerned that it be a separate GPM (either PSARC or > LSARC case) action, but that it be supportable during such > things as lid close/sleep/hibernate. > > >>>> How does this case provide for a screen lock on lid switching? >>>> >> >>This PSARC case doesn't directly handle the screen locking, but GPM >>will call the xscreensaver-command before the actions such as suspend >>or blank screen. > > > Too many GPMs, I presume you mean LSARC 2007/702 GPM. It would > be really good to have it specify its architectural operations. Yes, I meant the LSARC case. Thinking about it now, I should have called my case Philadelphia to help avoid some confusion :) We'll work together with the JDS folks to detail more about the architectural operations. Phi From gww@eng.sun.com Mon Feb 4 09:43:24 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m14HhOGo010166 for ; Mon, 4 Feb 2008 09:43:24 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m14HhN20026179; Mon, 4 Feb 2008 09:43:24 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVQ00G0B6KB6200@brm-avmta-1.central.sun.com>; Mon, 04 Feb 2008 10:43:23 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVQ006026K9U280@brm-avmta-1.central.sun.com>; Mon, 04 Feb 2008 10:43:21 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m14Hgw3K002733; Mon, 04 Feb 2008 09:42:58 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m14HfTX8014655; Mon, 04 Feb 2008 09:41:29 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m14HfTRw014654; Mon, 04 Feb 2008 09:41:29 -0800 (PST) Date: Mon, 04 Feb 2008 09:41:29 -0800 (PST) From: Gary Winiger Subject: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends To: lsarc@sun.com, psarc-ext@sun.com, tpm@eng.sun.com Cc: Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, gww@eng.sun.com, james.hughes@sun.com, john.plocher@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802041741.m14HfTRw014654@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5622 I wanted to update the case relative to the meeting I had with the case owner, submitter, and other's of the ON power management team after PSARC 30 Jan. As an aside, I'll not be present at 6 Feb PSARC and will be in and out on personal business the next couple weeks. Sorry for the length. I'm trying to bring too many things together in too short a time. I have to take some personal time over the next few weeks. This whole thing is looking more and more to me like a train wreck. I'm still quite concerned that there is no coordinated big picture of how things fit together from PSARC/2005/339 Tamarack: Removable Media Enhancements (which I was lead to believe introduced libpolkit interpreted by hald) and now PSARC/2007/679 CPUFreq HAL and PSARC/2008/021 HAL Power Mgmt Support which seemingly add to the Tamarack hald/libpolkit and finally LSARC/2007/702 GNOME Power Manager which seemingly calls the Tamarack hald/libpolkit to effect system power management. PSARC/2008/034 Defining Workstation Owner also may come into play. Recent communications with the Tamarack team now lead me to believe libpolkit and it's associated daemon are not part of Solaris, so I don't know what to think here. I'm leaning on the derail lever for 2008/021 and 2007/702. However, I'm concerned that will prove non-productive. Including/porting stuff from the GNOME community is fine. When it comes to system defaults, security considerations/interfaces, administration, ... I believe it needs to be looked at as a whole with how it models and fits with Solaris. IMO, we're seeing cases of what separate groups are good at doing; created a bunch of nice shiny components that are not necessarily integrated into a meaningful user/admin experience. What I'm asking/looking for is the architectural vision/guidance for the ARCs to be able to review the components as meaningful in fitting into the big picture. I've pointed out to the various recent project teams, that an umbrella case seems to be missing and have given the example of the Sparks umbrella, PSARC/2006/247 NSS2 (Sparks,Reno,Winchester,Duckwater) Umbrella case. As an ARC member, I believe it's my job to ask for that information. Not getting it, to get far more information from the individual cases than would be necessary with an Umbrella. As an engineer, I believe it's my job to contribute to the solution, thus the meeting 30 Jan. I'm happy to be involved further where ever I may be able to add to a solution. So what transpired at the 30 Jan meeting: 1) to avoid name confusion between PSARC/2008/021 and LSARC/2007/207, PSARC/2008/021 is to be renamed HAL Power Management Support. (This seems to have taken place) 2) the case 2008/021 owner, submitter and power mgmt project are to submit a new case designed to outline/specify the user out of the box experience based on the recent PSARC and LSARC power related cases. 3) I'm to engage the DE sponsor for the site doing the GPM GUI and other desktop ports to get the desktop/administrative interface architect(s) involved to describe the overall Sun/Solaris architecture in which these components fit. (I've engaged the DE sponsor, who agreed it's something he should facilitate, and I've engaged others in the power management organization.) Perhaps everything is there and I've just missed it. The folk I've been conversing with haven't seemed to point to the overall architecture. I continue to get the feeling from the individual project teams that it's "not my problem/charter, that's another teams problem/charter." I believe without information from 2 and 3 relative to defaults on install, the user/admin model (an umbrella), there's not enough information to understand the overall architecture of where these components fit and how they will make up a usable user/admin experience. Thus, I believe, these cases are either dependent on other cases, or are incompletely specified, in either case, I believe, they are not yet ready for approval. Perhaps there are additional business areas also involved relative to various uses of Solaris for such environments as Individual Desktop/Laptop, Shared Desktop, Server, ... However, I believe, independent of such business decisions there's missing architecture (or architectural information). In an out of band conversation, Artem pointed to the "Authorizations" screenshot relative to Ubuntu's use of PolicyKit: http://arstechnica.com/news.ars/post/20080202-first-look-ubuntu-8-04-hardy-heron-alpha-4.html Gosh, remember Viper/Seabreeze/AdminSuite3/SMC in one form or another since S7 ;-) Offline discussions with the power management group lead me to question the efficacy of the various stated default settings. It's my understanding that GPM (LSARC 2007/702) delivers the default settings. And that they are only for the logged in user. My original questions were about the "system" defaults, not the "user" defaults. If my understanding is correct when the user is not logged in, lid closure will do nothing, leaving a laptop up and running. This seems like it would discharge the battery far more quickly than desired. I can't say for sure how my MacBook came from the factory, but if I logout, and close the lid, it seems to "sleep". Perhaps I've misunderstood. And I'll ask again of all the related cases, what are the system defaults for power, especially lid? Out of the box, how does the user/admin modify them? How do they persist across logins and reboots? If committee (PSARC/LSARC) members believe I'm off in the ozone, I'll go back to my day other jobs and stand aside. Gary.. From sacadmin Mon Feb 4 09:43:36 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m14Hhauf010229 for ; Mon, 4 Feb 2008 09:43:36 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m14HhN20026179; Mon, 4 Feb 2008 09:43:24 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVQ00G0B6KB6200@brm-avmta-1.central.sun.com>; Mon, 04 Feb 2008 10:43:23 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVQ006026K9U280@brm-avmta-1.central.sun.com>; Mon, 04 Feb 2008 10:43:21 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m14Hgw3K002733; Mon, 04 Feb 2008 09:42:58 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m14HfTX8014655; Mon, 04 Feb 2008 09:41:29 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m14HfTRw014654; Mon, 04 Feb 2008 09:41:29 -0800 (PST) Date: Mon, 04 Feb 2008 09:41:29 -0800 (PST) From: Gary Winiger Subject: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends To: lsarc@sun.com, psarc-ext@sun.com, tpm@eng.sun.com Cc: Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, gww@eng.sun.com, james.hughes@sun.com, john.plocher@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802041741.m14HfTRw014654@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5622 I wanted to update the case relative to the meeting I had with the case owner, submitter, and other's of the ON power management team after PSARC 30 Jan. As an aside, I'll not be present at 6 Feb PSARC and will be in and out on personal business the next couple weeks. Sorry for the length. I'm trying to bring too many things together in too short a time. I have to take some personal time over the next few weeks. This whole thing is looking more and more to me like a train wreck. I'm still quite concerned that there is no coordinated big picture of how things fit together from PSARC/2005/339 Tamarack: Removable Media Enhancements (which I was lead to believe introduced libpolkit interpreted by hald) and now PSARC/2007/679 CPUFreq HAL and PSARC/2008/021 HAL Power Mgmt Support which seemingly add to the Tamarack hald/libpolkit and finally LSARC/2007/702 GNOME Power Manager which seemingly calls the Tamarack hald/libpolkit to effect system power management. PSARC/2008/034 Defining Workstation Owner also may come into play. Recent communications with the Tamarack team now lead me to believe libpolkit and it's associated daemon are not part of Solaris, so I don't know what to think here. I'm leaning on the derail lever for 2008/021 and 2007/702. However, I'm concerned that will prove non-productive. Including/porting stuff from the GNOME community is fine. When it comes to system defaults, security considerations/interfaces, administration, ... I believe it needs to be looked at as a whole with how it models and fits with Solaris. IMO, we're seeing cases of what separate groups are good at doing; created a bunch of nice shiny components that are not necessarily integrated into a meaningful user/admin experience. What I'm asking/looking for is the architectural vision/guidance for the ARCs to be able to review the components as meaningful in fitting into the big picture. I've pointed out to the various recent project teams, that an umbrella case seems to be missing and have given the example of the Sparks umbrella, PSARC/2006/247 NSS2 (Sparks,Reno,Winchester,Duckwater) Umbrella case. As an ARC member, I believe it's my job to ask for that information. Not getting it, to get far more information from the individual cases than would be necessary with an Umbrella. As an engineer, I believe it's my job to contribute to the solution, thus the meeting 30 Jan. I'm happy to be involved further where ever I may be able to add to a solution. So what transpired at the 30 Jan meeting: 1) to avoid name confusion between PSARC/2008/021 and LSARC/2007/207, PSARC/2008/021 is to be renamed HAL Power Management Support. (This seems to have taken place) 2) the case 2008/021 owner, submitter and power mgmt project are to submit a new case designed to outline/specify the user out of the box experience based on the recent PSARC and LSARC power related cases. 3) I'm to engage the DE sponsor for the site doing the GPM GUI and other desktop ports to get the desktop/administrative interface architect(s) involved to describe the overall Sun/Solaris architecture in which these components fit. (I've engaged the DE sponsor, who agreed it's something he should facilitate, and I've engaged others in the power management organization.) Perhaps everything is there and I've just missed it. The folk I've been conversing with haven't seemed to point to the overall architecture. I continue to get the feeling from the individual project teams that it's "not my problem/charter, that's another teams problem/charter." I believe without information from 2 and 3 relative to defaults on install, the user/admin model (an umbrella), there's not enough information to understand the overall architecture of where these components fit and how they will make up a usable user/admin experience. Thus, I believe, these cases are either dependent on other cases, or are incompletely specified, in either case, I believe, they are not yet ready for approval. Perhaps there are additional business areas also involved relative to various uses of Solaris for such environments as Individual Desktop/Laptop, Shared Desktop, Server, ... However, I believe, independent of such business decisions there's missing architecture (or architectural information). In an out of band conversation, Artem pointed to the "Authorizations" screenshot relative to Ubuntu's use of PolicyKit: http://arstechnica.com/news.ars/post/20080202-first-look-ubuntu-8-04-hardy-heron-alpha-4.html Gosh, remember Viper/Seabreeze/AdminSuite3/SMC in one form or another since S7 ;-) Offline discussions with the power management group lead me to question the efficacy of the various stated default settings. It's my understanding that GPM (LSARC 2007/702) delivers the default settings. And that they are only for the logged in user. My original questions were about the "system" defaults, not the "user" defaults. If my understanding is correct when the user is not logged in, lid closure will do nothing, leaving a laptop up and running. This seems like it would discharge the battery far more quickly than desired. I can't say for sure how my MacBook came from the factory, but if I logout, and close the lid, it seems to "sleep". Perhaps I've misunderstood. And I'll ask again of all the related cases, what are the system defaults for power, especially lid? Out of the box, how does the user/admin modify them? How do they persist across logins and reboots? If committee (PSARC/LSARC) members believe I'm off in the ozone, I'll go back to my day other jobs and stand aside. Gary.. From sacadmin Mon Feb 4 12:29:04 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m14KT34B022405 for ; Mon, 4 Feb 2008 12:29:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m14KSHfv015477; Mon, 4 Feb 2008 20:28:22 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVQ00703E789M00@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Feb 2008 12:28:20 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVQ00K9WE77JBE0@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Feb 2008 12:28:20 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m14KSJPG023654; Mon, 04 Feb 2008 12:28:19 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVQ00K01E22TP00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 04 Feb 2008 12:28:19 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVQ005CFE6PZL70@fe-sfbay-09.sun.com>; Mon, 04 Feb 2008 12:28:01 -0800 (PST) Date: Mon, 04 Feb 2008 12:27:59 -0800 From: John Plocher Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <200802041741.m14HfTRw014654@marduk.eng.sun.com> Sender: John.Plocher@sun.com To: Gary Winiger Cc: lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47A7754F.2070602@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1182 [Internal-only comment] Gary Winiger wrote: > I'm still quite concerned that there is no coordinated big picture of how You seem to be assuming that there is a top-down picture/plan of "how Linux/Gnome's security/policy/admin model is intended to map to Solaris, and how it all will be integrated together" that could be produced and shown to y'all. Maybe there is no coordinated big picture. Maybe the entire plan is to port selected components as needed, and to address the model mismatch on a piece by piece basis thru shims and scaffolds like libpolkit that map to Solaris RBAC. In this alternative, there is no big plan to build and deploy a SMC/Viper integrated admin gui for all this stuff, and no overarching vision for how things should behave outside of the user- logged-in-on-desktop environment. MAYBE THAT IS OK because there is a business decision being made that impacts the architecture of the system. In it, we are choosing to NOT spend resources on a holistic admin model, but instead leverage whatever comes our way from GNOME. Like many diet foods, less calories really means costs more and tastes worse; this doesn't seem much different :-( -John From sacadmin Mon Feb 4 12:29:04 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m14KT34D022405 for ; Mon, 4 Feb 2008 12:29:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m14KSHfv015477; Mon, 4 Feb 2008 20:28:22 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVQ00703E789M00@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Feb 2008 12:28:20 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVQ00K9WE77JBE0@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Feb 2008 12:28:20 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m14KSJPG023654; Mon, 04 Feb 2008 12:28:19 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVQ00K01E22TP00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 04 Feb 2008 12:28:19 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVQ005CFE6PZL70@fe-sfbay-09.sun.com>; Mon, 04 Feb 2008 12:28:01 -0800 (PST) Date: Mon, 04 Feb 2008 12:27:59 -0800 From: John Plocher Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <200802041741.m14HfTRw014654@marduk.eng.sun.com> Sender: John.Plocher@sun.com To: Gary Winiger Cc: lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47A7754F.2070602@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1182 [Internal-only comment] Gary Winiger wrote: > I'm still quite concerned that there is no coordinated big picture of how You seem to be assuming that there is a top-down picture/plan of "how Linux/Gnome's security/policy/admin model is intended to map to Solaris, and how it all will be integrated together" that could be produced and shown to y'all. Maybe there is no coordinated big picture. Maybe the entire plan is to port selected components as needed, and to address the model mismatch on a piece by piece basis thru shims and scaffolds like libpolkit that map to Solaris RBAC. In this alternative, there is no big plan to build and deploy a SMC/Viper integrated admin gui for all this stuff, and no overarching vision for how things should behave outside of the user- logged-in-on-desktop environment. MAYBE THAT IS OK because there is a business decision being made that impacts the architecture of the system. In it, we are choosing to NOT spend resources on a holistic admin model, but instead leverage whatever comes our way from GNOME. Like many diet foods, less calories really means costs more and tastes worse; this doesn't seem much different :-( -John From John.Fischer@sun.com Wed Feb 6 10:42:11 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16IgBQr019101; Wed, 6 Feb 2008 10:42:11 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m16IgB8E012887; Wed, 6 Feb 2008 10:42:11 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m16Ig87r007513; Wed, 6 Feb 2008 10:42:08 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVT00F01YGOTP00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM); Wed, 06 Feb 2008 10:42:07 -0800 (PST) Received: from [192.168.10.6] ([24.10.86.139]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVT00G0KYM4P4A0@fe-sfbay-09.sun.com>; Wed, 06 Feb 2008 10:42:05 -0800 (PST) Date: Wed, 06 Feb 2008 10:41:56 -0800 From: John Fischer Subject: Re: LSARC 2007/702 - GNOME Power Manager / PSARC 2008/021 - HAL Power Management Support Sender: John.Fischer@sun.com To: "Irene (Shi Ying) Huang" , PSARC-ext@sac.sfbay.sun.com, "phi.tran@sun.com >> Phi Tran" Cc: LSARC-ext@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Reply-to: John.Fischer@sun.com Message-id: <47A9FF74.8020407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.4 (X11/20070622) x_sac_archived: LSARC/2007/702 Status: RO Content-Length: 243 Irene and Phi, At the PSARC meeting today this case and PSARC 2008/021 HAL Power Management Support were both placed in "waiting need spec". The committees would like to see what is called an umbrella case for these projects. Thanks, John From John.Fischer@sun.com Wed Feb 6 10:42:11 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16IgBQr019101; Wed, 6 Feb 2008 10:42:11 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m16IgB8E012887; Wed, 6 Feb 2008 10:42:11 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m16Ig87r007513; Wed, 6 Feb 2008 10:42:08 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVT00F01YGOTP00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM); Wed, 06 Feb 2008 10:42:07 -0800 (PST) Received: from [192.168.10.6] ([24.10.86.139]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVT00G0KYM4P4A0@fe-sfbay-09.sun.com>; Wed, 06 Feb 2008 10:42:05 -0800 (PST) Date: Wed, 06 Feb 2008 10:41:56 -0800 From: John Fischer Subject: Re: LSARC 2007/702 - GNOME Power Manager / PSARC 2008/021 - HAL Power Management Support Sender: John.Fischer@sun.com To: "Irene (Shi Ying) Huang" , PSARC-ext@sac.sfbay.sun.com, "phi.tran@sun.com >> Phi Tran" Cc: LSARC-ext@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Reply-to: John.Fischer@sun.com Message-id: <47A9FF74.8020407@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 243 Irene and Phi, At the PSARC meeting today this case and PSARC 2008/021 HAL Power Management Support were both placed in "waiting need spec". The committees would like to see what is called an umbrella case for these projects. Thanks, John From sacadmin Sun Feb 10 17:57:58 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1B1vvDA027717 for ; Sun, 10 Feb 2008 17:57:58 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1B1vSFx005169; Mon, 11 Feb 2008 01:57:35 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW100F01XFYPE00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 10 Feb 2008 17:57:34 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW1002A3XFX3E90@nwk-avmta-1.sfbay.Sun.COM>; Sun, 10 Feb 2008 17:57:33 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1B1vUVV045438; Sun, 10 Feb 2008 17:57:30 -0800 (PST) Received: from [10.7.251.213] (punchin-rotondo.SFBay.Sun.COM [10.7.251.213]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m1B1vTr00729; Sun, 10 Feb 2008 17:57:29 -0800 (PST) Date: Sun, 10 Feb 2008 17:57:22 -0800 From: Scott Rotondo Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47A7754F.2070602@Sun.Com> To: John Plocher Cc: Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47AFAB82.3070808@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 2059 John Plocher wrote: > [Internal-only comment] > > Gary Winiger wrote: >> I'm still quite concerned that there is no coordinated big picture of how > > You seem to be assuming that there is a top-down picture/plan of "how > Linux/Gnome's security/policy/admin model is intended to map to Solaris, > and how it all will be integrated together" that could be produced and > shown to y'all. > > Maybe there is no coordinated big picture. Maybe the entire plan is to > port selected components as needed, and to address the model mismatch on > a piece by piece basis thru shims and scaffolds like libpolkit that map > to Solaris RBAC. In this alternative, there is no big plan to build and > deploy a SMC/Viper integrated admin gui for all this stuff, and no > overarching vision for how things should behave outside of the user- > logged-in-on-desktop environment. > > MAYBE THAT IS OK because there is a business decision being made > that impacts the architecture of the system. In it, we are choosing > to NOT spend resources on a holistic admin model, but instead leverage > whatever comes our way from GNOME. That's pretty much my understanding of the situation, and it probably is OK. We will continue to import huge amounts of code from Gnome and other open-source communities; most of it can and should be used as-is. However, some features in the OS (such as security administration) need to exist only once because multiple instances cannot coexist properly. [1] Code that duplicates features of that type will need some modification to merge with the existing feature. In this case, it seems clear that libpolkit should be implemented in terms of the existing RBAC authorization system. That way it can provide the API needed by various Gnome applications, while maintaining a single point of administrative control. Scott [1] As an example, what does it mean for an administrator to specify that only users A, B, and C have a given authorization if there is a parallel system that might grant equivalent powers to other users? From sacadmin Sun Feb 10 17:57:59 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1B1vvDC027717 for ; Sun, 10 Feb 2008 17:57:59 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1B1vSFx005169; Mon, 11 Feb 2008 01:57:35 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW100F01XFYPE00@nwk-avmta-1.sfbay.Sun.COM>; Sun, 10 Feb 2008 17:57:34 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW1002A3XFX3E90@nwk-avmta-1.sfbay.Sun.COM>; Sun, 10 Feb 2008 17:57:33 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1B1vUVV045438; Sun, 10 Feb 2008 17:57:30 -0800 (PST) Received: from [10.7.251.213] (punchin-rotondo.SFBay.Sun.COM [10.7.251.213]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id m1B1vTr00729; Sun, 10 Feb 2008 17:57:29 -0800 (PST) Date: Sun, 10 Feb 2008 17:57:22 -0800 From: Scott Rotondo Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47A7754F.2070602@Sun.Com> To: John Plocher Cc: Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47AFAB82.3070808@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 2059 John Plocher wrote: > [Internal-only comment] > > Gary Winiger wrote: >> I'm still quite concerned that there is no coordinated big picture of how > > You seem to be assuming that there is a top-down picture/plan of "how > Linux/Gnome's security/policy/admin model is intended to map to Solaris, > and how it all will be integrated together" that could be produced and > shown to y'all. > > Maybe there is no coordinated big picture. Maybe the entire plan is to > port selected components as needed, and to address the model mismatch on > a piece by piece basis thru shims and scaffolds like libpolkit that map > to Solaris RBAC. In this alternative, there is no big plan to build and > deploy a SMC/Viper integrated admin gui for all this stuff, and no > overarching vision for how things should behave outside of the user- > logged-in-on-desktop environment. > > MAYBE THAT IS OK because there is a business decision being made > that impacts the architecture of the system. In it, we are choosing > to NOT spend resources on a holistic admin model, but instead leverage > whatever comes our way from GNOME. That's pretty much my understanding of the situation, and it probably is OK. We will continue to import huge amounts of code from Gnome and other open-source communities; most of it can and should be used as-is. However, some features in the OS (such as security administration) need to exist only once because multiple instances cannot coexist properly. [1] Code that duplicates features of that type will need some modification to merge with the existing feature. In this case, it seems clear that libpolkit should be implemented in terms of the existing RBAC authorization system. That way it can provide the API needed by various Gnome applications, while maintaining a single point of administrative control. Scott [1] As an example, what does it mean for an administrator to specify that only users A, B, and C have a given authorization if there is a parallel system that might grant equivalent powers to other users? From sacadmin Mon Feb 11 10:31:34 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BIVX6j028087 for ; Mon, 11 Feb 2008 10:31:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1BIV3Zh018426; Tue, 12 Feb 2008 02:31:03 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW300J017FQAC00@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 11:31:02 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW3004557FPA2C0@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 11:31:01 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1BIV1P4005863; Mon, 11 Feb 2008 18:31:01 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW300J015CQSX00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM); Mon, 11 Feb 2008 11:31:01 -0700 (MST) Received: from [192.168.1.64] ([189.137.195.67]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW3001QQ7FF5V60@mail-amer.sun.com>; Mon, 11 Feb 2008 11:30:57 -0700 (MST) Date: Mon, 11 Feb 2008 12:30:52 -0600 From: Brian Cameron Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47AFAB82.3070808@sun.com> Sender: Brian.Cameron@sun.com To: Scott Rotondo Cc: John Plocher , Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B0945C.6090302@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> <47AFAB82.3070808@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 851 Scott: > In this case, it seems clear that libpolkit should be implemented in > terms of the existing RBAC authorization system. That way it can provide > the API needed by various Gnome applications, while maintaining a single > point of administrative control. Does the usage of libpolkit add any additional configuration? For example, I imagine we map between libpolkit HAL keys and RBAC keys. If we can manage this without the need for end-users to further configure things, then this is probably not a problem. However, it would be annoying it users needed to configure both RBAC and PolicyKit to get the behavior they want. In other words, I don't think providing an API needed by various GNOME applications is necessarily a good thing if it overly complicates how end-users have to configure their systems in terms of security. Brian From sacadmin Mon Feb 11 10:31:35 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BIVX6l028087 for ; Mon, 11 Feb 2008 10:31:34 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1BIV3Zh018426; Tue, 12 Feb 2008 02:31:03 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW300J017FQAC00@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 11:31:02 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW3004557FPA2C0@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 11:31:01 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1BIV1P4005863; Mon, 11 Feb 2008 18:31:01 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW300J015CQSX00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM); Mon, 11 Feb 2008 11:31:01 -0700 (MST) Received: from [192.168.1.64] ([189.137.195.67]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW3001QQ7FF5V60@mail-amer.sun.com>; Mon, 11 Feb 2008 11:30:57 -0700 (MST) Date: Mon, 11 Feb 2008 12:30:52 -0600 From: Brian Cameron Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47AFAB82.3070808@sun.com> Sender: Brian.Cameron@sun.com To: Scott Rotondo Cc: John Plocher , Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B0945C.6090302@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> <47AFAB82.3070808@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 851 Scott: > In this case, it seems clear that libpolkit should be implemented in > terms of the existing RBAC authorization system. That way it can provide > the API needed by various Gnome applications, while maintaining a single > point of administrative control. Does the usage of libpolkit add any additional configuration? For example, I imagine we map between libpolkit HAL keys and RBAC keys. If we can manage this without the need for end-users to further configure things, then this is probably not a problem. However, it would be annoying it users needed to configure both RBAC and PolicyKit to get the behavior they want. In other words, I don't think providing an API needed by various GNOME applications is necessarily a good thing if it overly complicates how end-users have to configure their systems in terms of security. Brian From sacadmin Mon Feb 11 10:55:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BItIgb028785 for ; Mon, 11 Feb 2008 10:55:18 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1BIt4RR020669; Mon, 11 Feb 2008 10:55:04 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW3007038JQVF00@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Feb 2008 10:55:02 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW3000YD8JNK7A0@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Feb 2008 10:54:59 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1BIswZl014097; Mon, 11 Feb 2008 10:54:58 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW30030188YZN00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM); Mon, 11 Feb 2008 10:54:58 -0800 (PST) Received: from [192.168.1.100] ([75.6.231.214]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW300CGE8JL0000@fe-sfbay-09.sun.com>; Mon, 11 Feb 2008 10:54:58 -0800 (PST) Date: Mon, 11 Feb 2008 10:53:47 -0800 From: Artem Kachitchkine Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47AFAB82.3070808@sun.com> Sender: Artem.Kachitchkin@sun.com To: Scott Rotondo Cc: John Plocher , Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B099BB.8010500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> <47AFAB82.3070808@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 607 > In this case, it seems clear that libpolkit should be implemented in > terms of the existing RBAC authorization system. At least to me, it is far from clear. PolicyKit evolved a lot since we reviewed Tamarack. libpolkit grew from a few to a few dozen functions, and in addition to libpolkit, there is now a DBus daemon, libpolkit-dbus, libpolkit-grant and PolicyKit-gnome. It gained new features that are not trivially mapped to RBAC (e.g. temporary authorizations and associating authorizations with sessions). It is a project-size effort to determine what's the right thing to do here. -Artem From sacadmin Mon Feb 11 10:55:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BItIgd028785 for ; Mon, 11 Feb 2008 10:55:18 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1BIt4RR020669; Mon, 11 Feb 2008 10:55:04 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW3007038JQVF00@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Feb 2008 10:55:02 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW3000YD8JNK7A0@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Feb 2008 10:54:59 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1BIswZl014097; Mon, 11 Feb 2008 10:54:58 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW30030188YZN00@fe-sfbay-09.sun.com> (original mail from Artem.Kachitchkin@Sun.COM); Mon, 11 Feb 2008 10:54:58 -0800 (PST) Received: from [192.168.1.100] ([75.6.231.214]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW300CGE8JL0000@fe-sfbay-09.sun.com>; Mon, 11 Feb 2008 10:54:58 -0800 (PST) Date: Mon, 11 Feb 2008 10:53:47 -0800 From: Artem Kachitchkine Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47AFAB82.3070808@sun.com> Sender: Artem.Kachitchkin@sun.com To: Scott Rotondo Cc: John Plocher , Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B099BB.8010500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> <47AFAB82.3070808@sun.com> User-Agent: Mozilla/5.0 Gecko/20040113 Status: RO Content-Length: 607 > In this case, it seems clear that libpolkit should be implemented in > terms of the existing RBAC authorization system. At least to me, it is far from clear. PolicyKit evolved a lot since we reviewed Tamarack. libpolkit grew from a few to a few dozen functions, and in addition to libpolkit, there is now a DBus daemon, libpolkit-dbus, libpolkit-grant and PolicyKit-gnome. It gained new features that are not trivially mapped to RBAC (e.g. temporary authorizations and associating authorizations with sessions). It is a project-size effort to determine what's the right thing to do here. -Artem From sacadmin Mon Feb 11 11:05:18 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BJ5HTC029059 for ; Mon, 11 Feb 2008 11:05:17 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1BJ4bJj001804; Tue, 12 Feb 2008 03:04:47 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW300L018ZXNJ00@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 12:04:45 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW30046N8ZW9XD0@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 12:04:44 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1BJ4irx016389; Mon, 11 Feb 2008 11:04:44 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW300C010AQKQ00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 11 Feb 2008 11:04:44 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW300CNO8ZR0060@fe-sfbay-09.sun.com>; Mon, 11 Feb 2008 11:04:39 -0800 (PST) Date: Mon, 11 Feb 2008 11:04:35 -0800 From: John Plocher Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47B0945C.6090302@sun.com> Sender: John.Plocher@sun.com To: Brian Cameron Cc: Scott Rotondo , Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B09C43.4000308@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> <47AFAB82.3070808@sun.com> <47B0945C.6090302@sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1055 Brian Cameron wrote: > Does the usage of libpolkit add any additional configuration? The hole I see is that we are only solving part of the problem. The libpolkit/hal layer interfaces well with RBAC from a read-only perspective - GNOME PwrMgt presumes HAL "auth keys" exist and are assigned to the laptop user; we map them to RBAC auths, and the queries "just work". For "writing auths", things seem different. The existing GNOME and Linux tools don't "do" RBAC admin - they do libpolkit and HAL and whatever Linux infrastructure exists to support them. On Solaris, we don't provide a way to associate the RBAC auths with the current user of the laptop. In fact, we don't seem to do the security/admin piece very well at all. This leaves us with a system that theoretically could power save when the user closes the lid, but we aren't setting up the user to have the RBAC auths to actually have it work. One could argue that this isn't a polkit issue, but rather an install or admin one. Either way, the end result is a dead battery. -John From sacadmin Mon Feb 11 11:05:19 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BJ5HTE029059 for ; Mon, 11 Feb 2008 11:05:18 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1BJ4bJj001804; Tue, 12 Feb 2008 03:04:47 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW300L018ZXNJ00@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 12:04:45 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW30046N8ZW9XD0@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 12:04:44 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1BJ4irx016389; Mon, 11 Feb 2008 11:04:44 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW300C010AQKQ00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 11 Feb 2008 11:04:44 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW300CNO8ZR0060@fe-sfbay-09.sun.com>; Mon, 11 Feb 2008 11:04:39 -0800 (PST) Date: Mon, 11 Feb 2008 11:04:35 -0800 From: John Plocher Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47B0945C.6090302@sun.com> Sender: John.Plocher@sun.com To: Brian Cameron Cc: Scott Rotondo , Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B09C43.4000308@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> <47AFAB82.3070808@sun.com> <47B0945C.6090302@sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1055 Brian Cameron wrote: > Does the usage of libpolkit add any additional configuration? The hole I see is that we are only solving part of the problem. The libpolkit/hal layer interfaces well with RBAC from a read-only perspective - GNOME PwrMgt presumes HAL "auth keys" exist and are assigned to the laptop user; we map them to RBAC auths, and the queries "just work". For "writing auths", things seem different. The existing GNOME and Linux tools don't "do" RBAC admin - they do libpolkit and HAL and whatever Linux infrastructure exists to support them. On Solaris, we don't provide a way to associate the RBAC auths with the current user of the laptop. In fact, we don't seem to do the security/admin piece very well at all. This leaves us with a system that theoretically could power save when the user closes the lid, but we aren't setting up the user to have the RBAC auths to actually have it work. One could argue that this isn't a polkit issue, but rather an install or admin one. Either way, the end result is a dead battery. -John From sacadmin Mon Feb 11 11:47:06 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BJl6O8029607 for ; Mon, 11 Feb 2008 11:47:06 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1BJkkfk045264; Mon, 11 Feb 2008 12:46:51 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW30061BAY2PA00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Feb 2008 11:46:50 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW30018CAY1C0E0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Feb 2008 11:46:49 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1BJknk8022374; Mon, 11 Feb 2008 11:46:49 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW300A01AKFQM00@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Mon, 11 Feb 2008 11:46:49 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW300BW6AXZH6C0@fe-sfbay-09.sun.com>; Mon, 11 Feb 2008 11:46:48 -0800 (PST) Date: Mon, 11 Feb 2008 11:56:25 -0800 From: Phi Tran Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47B099BB.8010500@sun.com> Sender: Phi.Tran@sun.com To: Artem Kachitchkine Cc: Scott Rotondo , John Plocher , Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B0A869.8050705@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> <47AFAB82.3070808@sun.com> <47B099BB.8010500@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 923 Artem Kachitchkine wrote: > >> In this case, it seems clear that libpolkit should be implemented in >> terms of the existing RBAC authorization system. > > > At least to me, it is far from clear. PolicyKit evolved a lot since we > reviewed Tamarack. libpolkit grew from a few to a few dozen functions, > and in addition to libpolkit, there is now a DBus daemon, > libpolkit-dbus, libpolkit-grant and PolicyKit-gnome. It gained new > features that are not trivially mapped to RBAC (e.g. temporary > authorizations and associating authorizations with sessions). > > It is a project-size effort to determine what's the right thing to do here. > > -Artem I agree there's a larger scope now for PolicyKit and it's new features may be needed for applications that make use of the new features such as session authorizations. GPM will care only if the user is root or console owner which can be handled by RBAC. Phi From sacadmin Mon Feb 11 11:47:06 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BJl6OA029607 for ; Mon, 11 Feb 2008 11:47:06 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1BJkkfk045264; Mon, 11 Feb 2008 12:46:51 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW30061BAY2PA00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Feb 2008 11:46:50 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW30018CAY1C0E0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 11 Feb 2008 11:46:49 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1BJknk8022374; Mon, 11 Feb 2008 11:46:49 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW300A01AKFQM00@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Mon, 11 Feb 2008 11:46:49 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW300BW6AXZH6C0@fe-sfbay-09.sun.com>; Mon, 11 Feb 2008 11:46:48 -0800 (PST) Date: Mon, 11 Feb 2008 11:56:25 -0800 From: Phi Tran Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47B099BB.8010500@sun.com> Sender: Phi.Tran@sun.com To: Artem Kachitchkine Cc: Scott Rotondo , John Plocher , Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B0A869.8050705@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> <47AFAB82.3070808@sun.com> <47B099BB.8010500@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 923 Artem Kachitchkine wrote: > >> In this case, it seems clear that libpolkit should be implemented in >> terms of the existing RBAC authorization system. > > > At least to me, it is far from clear. PolicyKit evolved a lot since we > reviewed Tamarack. libpolkit grew from a few to a few dozen functions, > and in addition to libpolkit, there is now a DBus daemon, > libpolkit-dbus, libpolkit-grant and PolicyKit-gnome. It gained new > features that are not trivially mapped to RBAC (e.g. temporary > authorizations and associating authorizations with sessions). > > It is a project-size effort to determine what's the right thing to do here. > > -Artem I agree there's a larger scope now for PolicyKit and it's new features may be needed for applications that make use of the new features such as session authorizations. GPM will care only if the user is root or console owner which can be handled by RBAC. Phi From sacadmin Mon Feb 11 12:44:15 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BKiF0f002979 for ; Mon, 11 Feb 2008 12:44:15 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1BKi08B005860; Mon, 11 Feb 2008 12:44:00 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW300609DLC3600@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 13:44:00 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.228.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW30002TDLBUZ50@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 13:43:59 -0700 (MST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id m1BKhw1p496727; Mon, 11 Feb 2008 12:43:58 -0800 (PST) Date: Mon, 11 Feb 2008 12:43:15 -0800 (PST) From: Randy Fishel Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends To: John.Plocher@sun.com, scott.rotondo@sun.com Cc: gww@eng.sun.com, lsarc@sun.com, psarc@sun.com, tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Reply-to: Randy Fishel Message-id: <200802112043.m1BKhw1p496727@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2698 This message seems to imply that the "spec" being requested by PSARC is *not* the spec that is being generated. PSARC (and particularly one of it's members) has requested that the project team (or a related project team) create a "Big Picture" spec. So the question for PSARC, is "what is the scope of the requested spec to satisfy the 'waiting need spec' requirements for these cases", as "what is the big picture" is way too broad (and discussions with several ARC contributors has come up with significantly different answers)? ---- Randy > > John Plocher wrote: > > [Internal-only comment] > > > > Gary Winiger wrote: > >> I'm still quite concerned that there is no coordinated big picture of how > > > > You seem to be assuming that there is a top-down picture/plan of "how > > Linux/Gnome's security/policy/admin model is intended to map to Solaris, > > and how it all will be integrated together" that could be produced and > > shown to y'all. > > > > Maybe there is no coordinated big picture. Maybe the entire plan is to > > port selected components as needed, and to address the model mismatch on > > a piece by piece basis thru shims and scaffolds like libpolkit that map > > to Solaris RBAC. In this alternative, there is no big plan to build and > > deploy a SMC/Viper integrated admin gui for all this stuff, and no > > overarching vision for how things should behave outside of the user- > > logged-in-on-desktop environment. > > > > MAYBE THAT IS OK because there is a business decision being made > > that impacts the architecture of the system. In it, we are choosing > > to NOT spend resources on a holistic admin model, but instead leverage > > whatever comes our way from GNOME. > > That's pretty much my understanding of the situation, and it probably is > OK. We will continue to import huge amounts of code from Gnome and other > open-source communities; most of it can and should be used as-is. > However, some features in the OS (such as security administration) need > to exist only once because multiple instances cannot coexist properly. > [1] Code that duplicates features of that type will need some > modification to merge with the existing feature. > > In this case, it seems clear that libpolkit should be implemented in > terms of the existing RBAC authorization system. That way it can provide > the API needed by various Gnome applications, while maintaining a single > point of administrative control. > > Scott > > [1] As an example, what does it mean for an administrator to specify > that only users A, B, and C have a given authorization if there is a > parallel system that might grant equivalent powers to other users? From sacadmin Mon Feb 11 12:44:15 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BKiF0h002979 for ; Mon, 11 Feb 2008 12:44:15 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1BKi08B005860; Mon, 11 Feb 2008 12:44:00 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW300609DLC3600@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 13:44:00 -0700 (MST) Received: from jurassic.eng.sun.com ([129.146.228.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW30002TDLBUZ50@brm-avmta-1.central.sun.com>; Mon, 11 Feb 2008 13:43:59 -0700 (MST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id m1BKhw1p496727; Mon, 11 Feb 2008 12:43:58 -0800 (PST) Date: Mon, 11 Feb 2008 12:43:15 -0800 (PST) From: Randy Fishel Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends To: John.Plocher@sun.com, scott.rotondo@sun.com Cc: gww@eng.sun.com, lsarc@sun.com, psarc@sun.com, tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Phi.Tran@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Reply-to: Randy Fishel Message-id: <200802112043.m1BKhw1p496727@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2698 This message seems to imply that the "spec" being requested by PSARC is *not* the spec that is being generated. PSARC (and particularly one of it's members) has requested that the project team (or a related project team) create a "Big Picture" spec. So the question for PSARC, is "what is the scope of the requested spec to satisfy the 'waiting need spec' requirements for these cases", as "what is the big picture" is way too broad (and discussions with several ARC contributors has come up with significantly different answers)? ---- Randy > > John Plocher wrote: > > [Internal-only comment] > > > > Gary Winiger wrote: > >> I'm still quite concerned that there is no coordinated big picture of how > > > > You seem to be assuming that there is a top-down picture/plan of "how > > Linux/Gnome's security/policy/admin model is intended to map to Solaris, > > and how it all will be integrated together" that could be produced and > > shown to y'all. > > > > Maybe there is no coordinated big picture. Maybe the entire plan is to > > port selected components as needed, and to address the model mismatch on > > a piece by piece basis thru shims and scaffolds like libpolkit that map > > to Solaris RBAC. In this alternative, there is no big plan to build and > > deploy a SMC/Viper integrated admin gui for all this stuff, and no > > overarching vision for how things should behave outside of the user- > > logged-in-on-desktop environment. > > > > MAYBE THAT IS OK because there is a business decision being made > > that impacts the architecture of the system. In it, we are choosing > > to NOT spend resources on a holistic admin model, but instead leverage > > whatever comes our way from GNOME. > > That's pretty much my understanding of the situation, and it probably is > OK. We will continue to import huge amounts of code from Gnome and other > open-source communities; most of it can and should be used as-is. > However, some features in the OS (such as security administration) need > to exist only once because multiple instances cannot coexist properly. > [1] Code that duplicates features of that type will need some > modification to merge with the existing feature. > > In this case, it seems clear that libpolkit should be implemented in > terms of the existing RBAC authorization system. That way it can provide > the API needed by various Gnome applications, while maintaining a single > point of administrative control. > > Scott > > [1] As an example, what does it mean for an administrator to specify > that only users A, B, and C have a given authorization if there is a > parallel system that might grant equivalent powers to other users? From sacadmin Mon Feb 11 12:52:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BKq0ux003070 for ; Mon, 11 Feb 2008 12:52:00 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1BKpUUd013810; Tue, 12 Feb 2008 04:51:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW300C0BDXRKA00@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Feb 2008 12:51:27 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW300BPGDXQNX10@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Feb 2008 12:51:26 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1BKpQD8028667; Mon, 11 Feb 2008 12:51:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW300C01DV1LB00@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Mon, 11 Feb 2008 12:51:26 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW30026FDXP8950@fe-sfbay-10.sun.com>; Mon, 11 Feb 2008 12:51:26 -0800 (PST) Date: Mon, 11 Feb 2008 13:01:02 -0800 From: Phi Tran Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47B09C43.4000308@Sun.Com> Sender: Phi.Tran@sun.com To: John Plocher Cc: Brian Cameron , Scott Rotondo , Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B0B78E.3040204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> <47AFAB82.3070808@sun.com> <47B0945C.6090302@sun.com> <47B09C43.4000308@Sun.Com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 1483 John Plocher wrote: > Brian Cameron wrote: > >> Does the usage of libpolkit add any additional configuration? > > > The hole I see is that we are only solving part of the problem. > > The libpolkit/hal layer interfaces well with RBAC from a read-only > perspective - GNOME PwrMgt presumes HAL "auth keys" exist and are > assigned to the laptop user; we map them to RBAC auths, and the > queries "just work". > > For "writing auths", things seem different. The existing GNOME > and Linux tools don't "do" RBAC admin - they do libpolkit and > HAL and whatever Linux infrastructure exists to support them. Since we are replacing Gnome security policies with RBAC, we can use our admin tool to modify user privileges. > On Solaris, we don't provide a way to associate the RBAC auths with > the current user of the laptop. In fact, we don't seem to do the > security/admin piece very well at all. One can use the admin tool under "Users and Groups" or edit /etc/user_attr file by hand to change user auths from any defaults. > > This leaves us with a system that theoretically could power save > when the user closes the lid, but we aren't setting up the user to > have the RBAC auths to actually have it work. > > One could argue that this isn't a polkit issue, but rather an install > or admin one. Either way, the end result is a dead battery. For GPM, the expectations are that the root or console owner will have the RBAC auths to modify lid actions by default. Phi From sacadmin Mon Feb 11 12:52:02 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1BKq0v1003070 for ; Mon, 11 Feb 2008 12:52:02 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1BKpUUd013810; Tue, 12 Feb 2008 04:51:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW300C0BDXRKA00@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Feb 2008 12:51:27 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW300BPGDXQNX10@nwk-avmta-2.sfbay.sun.com>; Mon, 11 Feb 2008 12:51:26 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1BKpQD8028667; Mon, 11 Feb 2008 12:51:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW300C01DV1LB00@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Mon, 11 Feb 2008 12:51:26 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW30026FDXP8950@fe-sfbay-10.sun.com>; Mon, 11 Feb 2008 12:51:26 -0800 (PST) Date: Mon, 11 Feb 2008 13:01:02 -0800 From: Phi Tran Subject: Re: About 2008/021 HAL Power Management LSARC/2007/702 GPM and friends In-reply-to: <47B09C43.4000308@Sun.Com> Sender: Phi.Tran@sun.com To: John Plocher Cc: Brian Cameron , Scott Rotondo , Gary Winiger , lsarc@sun.com, "psarc@sun.com" , tpm@eng.sun.com, Artem.Kachitchkin@sun.com, David.Chieu@sun.com, Glenn.Faden@sun.com, Irene.Huang@sun.com, Jim.Li@sun.com, Randy.Fishel@sun.com, dchieu@sac.sfbay.sun.com, djb@eng.sun.com, James.Hughes@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B0B78E.3040204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802041741.m14HfTRw014654@marduk.eng.sun.com> <47A7754F.2070602@Sun.Com> <47AFAB82.3070808@sun.com> <47B0945C.6090302@sun.com> <47B09C43.4000308@Sun.Com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 1483 John Plocher wrote: > Brian Cameron wrote: > >> Does the usage of libpolkit add any additional configuration? > > > The hole I see is that we are only solving part of the problem. > > The libpolkit/hal layer interfaces well with RBAC from a read-only > perspective - GNOME PwrMgt presumes HAL "auth keys" exist and are > assigned to the laptop user; we map them to RBAC auths, and the > queries "just work". > > For "writing auths", things seem different. The existing GNOME > and Linux tools don't "do" RBAC admin - they do libpolkit and > HAL and whatever Linux infrastructure exists to support them. Since we are replacing Gnome security policies with RBAC, we can use our admin tool to modify user privileges. > On Solaris, we don't provide a way to associate the RBAC auths with > the current user of the laptop. In fact, we don't seem to do the > security/admin piece very well at all. One can use the admin tool under "Users and Groups" or edit /etc/user_attr file by hand to change user auths from any defaults. > > This leaves us with a system that theoretically could power save > when the user closes the lid, but we aren't setting up the user to > have the RBAC auths to actually have it work. > > One could argue that this isn't a polkit issue, but rather an install > or admin one. Either way, the end result is a dead battery. For GPM, the expectations are that the root or console owner will have the RBAC auths to modify lid actions by default. Phi From gww@eng.sun.com Wed Feb 13 12:14:50 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1DKEnt1008134 for ; Wed, 13 Feb 2008 12:14:50 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1DKEjQe002591; Thu, 14 Feb 2008 04:14:48 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW70030H1KJ9200@brm-avmta-1.central.sun.com>; Wed, 13 Feb 2008 13:14:43 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW70015Z1KJ6820@brm-avmta-1.central.sun.com>; Wed, 13 Feb 2008 13:14:43 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1DKEhM9053692; Wed, 13 Feb 2008 12:14:43 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1DKEsgu003938; Wed, 13 Feb 2008 12:14:54 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1DKEsuK003937; Wed, 13 Feb 2008 12:14:54 -0800 (PST) Date: Wed, 13 Feb 2008 12:14:54 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com Cc: solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802132014.m1DKEsuK003937@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 950 > Lid > --- > > GPM allows the user to set actions for lid close such as suspend, > hibernate, and shutdown. Suspend and hibernate actions will be > > Power Button > ------------ > > GPM allows for the configuration of power button actions such as > shutdown, suspend, and hibernate. These actions will be allowed How does this project meet the audit requirements for auditing a system discontinuity? Before this project, when the system is shutdown (halt(1M), reboot(1M), uadmin(1M)), an audit record is written indicating the start of a discontinuity, the audit trail is flushed to disk, the current audit trail file closed, the audit service is temporarially disabled. Upon reboot, the kernel genereates a boot audit record. When the audit service is started during svc.startd processing, a new audit trail file is created and the boot audit record is recorded in that file. Note also prom entry and exit are audited. Gary.. From Phi.Tran@sun.com Wed Feb 13 12:34:39 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1DKYcLI008282 for ; Wed, 13 Feb 2008 12:34:39 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1DKYYwQ009629; Thu, 14 Feb 2008 04:34:37 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW700K072HN8H00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Feb 2008 12:34:35 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW700B902HNG5A0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Feb 2008 12:34:35 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1DKYZaL017353; Wed, 13 Feb 2008 12:34:35 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW700F012FA9F00@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Wed, 13 Feb 2008 12:34:35 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW700LYU2HMPX70@fe-sfbay-10.sun.com>; Wed, 13 Feb 2008 12:34:34 -0800 (PST) Date: Wed, 13 Feb 2008 12:44:12 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200802132014.m1DKEsuK003937@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B3569C.5040103@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802132014.m1DKEsuK003937@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 1161 Gary Winiger wrote: >>Lid >>--- >> >>GPM allows the user to set actions for lid close such as suspend, >>hibernate, and shutdown. Suspend and hibernate actions will be >> >>Power Button >>------------ >> >>GPM allows for the configuration of power button actions such as >>shutdown, suspend, and hibernate. These actions will be allowed > > > How does this project meet the audit requirements for > auditing a system discontinuity? > > Before this project, when the system is shutdown (halt(1M), > reboot(1M), uadmin(1M)), an audit record is written indicating > the start of a discontinuity, the audit trail is flushed to > disk, the current audit trail file closed, the audit service is > temporarially disabled. Upon reboot, the kernel genereates > a boot audit record. When the audit service is started > during svc.startd processing, a new audit trail file is created > and the boot audit record is recorded in that file. > > Note also prom entry and exit are audited. > > Gary.. The base calls will be init(1M), reboot(1M), and uadmin(1M) which are all audited like you said. Are you saying the auditing there isn't sufficient? Phi From gww@eng.sun.com Wed Feb 13 13:01:04 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1DL13KV008853 for ; Wed, 13 Feb 2008 13:01:03 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1DL13kA045169; Wed, 13 Feb 2008 14:01:03 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW7000273PQTL00@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Feb 2008 13:01:02 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW700IQ93PO3Z80@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Feb 2008 13:01:00 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1DL0xr4014385; Wed, 13 Feb 2008 13:00:59 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1DL1Bo0007884; Wed, 13 Feb 2008 13:01:11 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1DL1B8e007883; Wed, 13 Feb 2008 13:01:11 -0800 (PST) Date: Wed, 13 Feb 2008 13:01:11 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: gww@eng.sun.com, Phi.Tran@sun.com Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802132101.m1DL1B8e007883@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1998 > From Phi.Tran@sun.com Wed Feb 13 12:34:52 2008 > Date: Wed, 13 Feb 2008 12:44:12 -0800 > From: Phi Tran > Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout > 01/23/2008] > To: Gary Winiger > Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, > tamarack-core@sun.com, x86power-iteam@sun.com > Content-transfer-encoding: 7BIT > X-Accept-Language: en-us, en > User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 > > Gary Winiger wrote: > >>Lid > >>--- > >> > >>GPM allows the user to set actions for lid close such as suspend, > >>hibernate, and shutdown. Suspend and hibernate actions will be > >> > >>Power Button > >>------------ > >> > >>GPM allows for the configuration of power button actions such as > >>shutdown, suspend, and hibernate. These actions will be allowed > > > > > > How does this project meet the audit requirements for > > auditing a system discontinuity? > > > > Before this project, when the system is shutdown (halt(1M), > > reboot(1M), uadmin(1M)), an audit record is written indicating > > the start of a discontinuity, the audit trail is flushed to > > disk, the current audit trail file closed, the audit service is > > temporarially disabled. Upon reboot, the kernel genereates > > a boot audit record. When the audit service is started > > during svc.startd processing, a new audit trail file is created > > and the boot audit record is recorded in that file. > > > > Note also prom entry and exit are audited. > > > > Gary.. > > The base calls will be init(1M), reboot(1M), and uadmin(1M) which are > all audited like you said. Are you saying the auditing there isn't > sufficient? Are you saying you run init/reboot/uadmin (but not halt) in the full context of the user? If so that's sufficient for initiating the discontinuity. When the system comes out of suspended animation, is kernel main() run? Gary.. From Phi.Tran@sun.com Wed Feb 13 14:00:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1DM0Kqb009816 for ; Wed, 13 Feb 2008 14:00:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1DM0GuY025130; Wed, 13 Feb 2008 22:00:18 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW70031Z6GG9400@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Feb 2008 14:00:16 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW700ICZ6GG42B0@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Feb 2008 14:00:16 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1DM0F0m003211; Wed, 13 Feb 2008 14:00:15 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW700601676V000@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Wed, 13 Feb 2008 14:00:15 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW70036U6GEWZ40@fe-sfbay-09.sun.com>; Wed, 13 Feb 2008 14:00:15 -0800 (PST) Date: Wed, 13 Feb 2008 14:09:52 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200802132101.m1DL1B8e007883@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B36AB0.5050506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802132101.m1DL1B8e007883@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 2348 Gary Winiger wrote: >>From Phi.Tran@sun.com Wed Feb 13 12:34:52 2008 >>Date: Wed, 13 Feb 2008 12:44:12 -0800 >>From: Phi Tran >>Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout >> 01/23/2008] >>To: Gary Winiger >>Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, >> tamarack-core@sun.com, x86power-iteam@sun.com >>Content-transfer-encoding: 7BIT >>X-Accept-Language: en-us, en >>User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 >> >>Gary Winiger wrote: >> >>>>Lid >>>>--- >>>> >>>>GPM allows the user to set actions for lid close such as suspend, >>>>hibernate, and shutdown. Suspend and hibernate actions will be >>>> >>>>Power Button >>>>------------ >>>> >>>>GPM allows for the configuration of power button actions such as >>>>shutdown, suspend, and hibernate. These actions will be allowed >>> >>> >>> How does this project meet the audit requirements for >>> auditing a system discontinuity? >>> >>> Before this project, when the system is shutdown (halt(1M), >>> reboot(1M), uadmin(1M)), an audit record is written indicating >>> the start of a discontinuity, the audit trail is flushed to >>> disk, the current audit trail file closed, the audit service is >>> temporarially disabled. Upon reboot, the kernel genereates >>> a boot audit record. When the audit service is started >>> during svc.startd processing, a new audit trail file is created >>> and the boot audit record is recorded in that file. >>> >>> Note also prom entry and exit are audited. >>> >>>Gary.. >> >>The base calls will be init(1M), reboot(1M), and uadmin(1M) which are >>all audited like you said. Are you saying the auditing there isn't >>sufficient? > > > Are you saying you run init/reboot/uadmin (but not halt) in the > full context of the user? If so that's sufficient for initiating > the discontinuity. > When the system comes out of suspended animation, is kernel main() > run? Yes, the init/reboot/uadmin calls run in the full context of the user. Halt is not used since it doesn't shut down SMF services cleanly. The kernel was suspended, so on a resume like any suspended process would start running again. That's my simplified answer :), but the power management group would have more details if needed. Phi From gww@eng.sun.com Wed Feb 13 15:15:10 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1DNFAIv012536 for ; Wed, 13 Feb 2008 15:15:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1DNF9kv013797; Wed, 13 Feb 2008 16:15:09 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW7006039X6MV00@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Feb 2008 15:15:06 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW7006IV9X61110@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Feb 2008 15:15:06 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1DNF65D029411; Wed, 13 Feb 2008 15:15:06 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1DNFH7p008083; Wed, 13 Feb 2008 15:15:17 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1DNFHKu008082; Wed, 13 Feb 2008 15:15:17 -0800 (PST) Date: Wed, 13 Feb 2008 15:15:17 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: gww@eng.sun.com, Phi.Tran@sun.com Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802132315.m1DNFHKu008082@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1816 > >>> How does this project meet the audit requirements for > >>> auditing a system discontinuity? > >>> > >>> Before this project, when the system is shutdown (halt(1M), > >>> reboot(1M), uadmin(1M)), an audit record is written indicating > >>> the start of a discontinuity, the audit trail is flushed to > >>> disk, the current audit trail file closed, the audit service is > >>> temporarially disabled. Upon reboot, the kernel genereates > >>> a boot audit record. When the audit service is started > >>> during svc.startd processing, a new audit trail file is created > >>> and the boot audit record is recorded in that file. > >>> > >>> Note also prom entry and exit are audited. > >>> > >>>Gary.. > >> > >>The base calls will be init(1M), reboot(1M), and uadmin(1M) which are > >>all audited like you said. Are you saying the auditing there isn't > >>sufficient? > > > > > > Are you saying you run init/reboot/uadmin (but not halt) in the > > full context of the user? If so that's sufficient for initiating > > the discontinuity. > > When the system comes out of suspended animation, is kernel main() > > run? > > Yes, the init/reboot/uadmin calls run in the full context of the user. > Halt is not used since it doesn't shut down SMF services cleanly. > > The kernel was suspended, so on a resume like any suspended process > would start running again. That's my simplified answer :), but the > power management group would have more details if needed. Not really. When the kernel resumes, I would presume it stats at the next kernel instruction following the instruction that caused it to go into suspended animation. I would presume it does not run genuinx:main() again that starts the system fresh in a reboot, so I ask how is the resumed from suspended animation audited? Gary.. From Phi.Tran@sun.com Wed Feb 13 15:37:19 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1DNbJE3013080 for ; Wed, 13 Feb 2008 15:37:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1DNbGD7020372; Wed, 13 Feb 2008 16:37:19 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW700J1JAY5AF00@brm-avmta-1.central.sun.com>; Wed, 13 Feb 2008 16:37:17 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW700ER6AY4ZC30@brm-avmta-1.central.sun.com>; Wed, 13 Feb 2008 16:37:17 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1DNbG0Y014008; Wed, 13 Feb 2008 15:37:16 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW700K01AQP3100@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Wed, 13 Feb 2008 15:37:16 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW7009LDAY47FF0@fe-sfbay-10.sun.com>; Wed, 13 Feb 2008 15:37:16 -0800 (PST) Date: Wed, 13 Feb 2008 15:46:54 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200802132315.m1DNFHKu008082@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B3816E.3090705@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802132315.m1DNFHKu008082@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 2065 Gary Winiger wrote: >>>>> How does this project meet the audit requirements for >>>>> auditing a system discontinuity? >>>>> >>>>> Before this project, when the system is shutdown (halt(1M), >>>>> reboot(1M), uadmin(1M)), an audit record is written indicating >>>>> the start of a discontinuity, the audit trail is flushed to >>>>> disk, the current audit trail file closed, the audit service is >>>>> temporarially disabled. Upon reboot, the kernel genereates >>>>> a boot audit record. When the audit service is started >>>>> during svc.startd processing, a new audit trail file is created >>>>> and the boot audit record is recorded in that file. >>>>> >>>>> Note also prom entry and exit are audited. >>>>> >>>>>Gary.. >>>> >>>>The base calls will be init(1M), reboot(1M), and uadmin(1M) which are >>>>all audited like you said. Are you saying the auditing there isn't >>>>sufficient? >>> >>> >>> Are you saying you run init/reboot/uadmin (but not halt) in the >>> full context of the user? If so that's sufficient for initiating >>> the discontinuity. >>> When the system comes out of suspended animation, is kernel main() >>> run? >> >>Yes, the init/reboot/uadmin calls run in the full context of the user. >>Halt is not used since it doesn't shut down SMF services cleanly. >> >>The kernel was suspended, so on a resume like any suspended process >>would start running again. That's my simplified answer :), but the >>power management group would have more details if needed. > > > Not really. When the kernel resumes, I would presume it stats > at the next kernel instruction following the instruction that > caused it to go into suspended animation. I would presume it > does not run genuinx:main() again that starts the system fresh > in a reboot, so I ask how is the resumed from suspended animation > audited? > I agree that any process resumed should start at the next instruction. As for the auditing of resume, I don't know how exactly it was done. I'll have to look up the bug and code that was integrated for this auditing. Phi From Phi.Tran@sun.com Wed Feb 13 16:22:16 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1E0MFZt015220 for ; Wed, 13 Feb 2008 16:22:15 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1E0MCYf031160; Wed, 13 Feb 2008 17:22:14 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW70092FD11GU00@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Feb 2008 16:22:13 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW7006OYD0X0Z50@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Feb 2008 16:22:10 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1E0M9nq018530; Wed, 13 Feb 2008 16:22:09 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW7002017L4M000@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Wed, 13 Feb 2008 16:22:09 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW700KD8D0T7Q60@fe-sfbay-09.sun.com>; Wed, 13 Feb 2008 16:22:05 -0800 (PST) Date: Wed, 13 Feb 2008 16:31:43 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <47B3816E.3090705@Sun.COM> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B38BEF.8040802@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802132315.m1DNFHKu008082@marduk.eng.sun.com> <47B3816E.3090705@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 2392 Phi Tran wrote: > Gary Winiger wrote: > >>>>>> How does this project meet the audit requirements for >>>>>> auditing a system discontinuity? >>>>>> >>>>>> Before this project, when the system is shutdown (halt(1M), >>>>>> reboot(1M), uadmin(1M)), an audit record is written indicating >>>>>> the start of a discontinuity, the audit trail is flushed to >>>>>> disk, the current audit trail file closed, the audit service is >>>>>> temporarially disabled. Upon reboot, the kernel genereates >>>>>> a boot audit record. When the audit service is started >>>>>> during svc.startd processing, a new audit trail file is created >>>>>> and the boot audit record is recorded in that file. >>>>>> >>>>>> Note also prom entry and exit are audited. >>>>>> >>>>>> Gary.. >>>>> >>>>> >>>>> The base calls will be init(1M), reboot(1M), and uadmin(1M) which are >>>>> all audited like you said. Are you saying the auditing there isn't >>>>> sufficient? >>>> >>>> >>>> >>>> Are you saying you run init/reboot/uadmin (but not halt) in the >>>> full context of the user? If so that's sufficient for initiating >>>> the discontinuity. >>>> When the system comes out of suspended animation, is kernel main() >>>> run? >>> >>> >>> Yes, the init/reboot/uadmin calls run in the full context of the user. >>> Halt is not used since it doesn't shut down SMF services cleanly. >>> >>> The kernel was suspended, so on a resume like any suspended process >>> would start running again. That's my simplified answer :), but the >>> power management group would have more details if needed. >> >> >> >> Not really. When the kernel resumes, I would presume it stats >> at the next kernel instruction following the instruction that >> caused it to go into suspended animation. I would presume it >> does not run genuinx:main() again that starts the system fresh >> in a reboot, so I ask how is the resumed from suspended animation >> audited? >> > > I agree that any process resumed should start at the next instruction. > > As for the auditing of resume, I don't know how exactly it was done. > I'll have to look up the bug and code that was integrated for this > auditing. The auditing of suspend is handled by the uadmin.c code. It creates an audit record and the ends the auditing session before the actual suspend. Phi From Phi.Tran@sun.com Wed Feb 13 16:26:50 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1E0QnLh015260 for ; Wed, 13 Feb 2008 16:26:49 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1E0Qlvv012257; Thu, 14 Feb 2008 08:26:48 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW700J07D8M8800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Feb 2008 16:26:46 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW7002VND8LDO90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Feb 2008 16:26:45 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1E0QjjA018975; Wed, 13 Feb 2008 16:26:45 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW700I01D7Z6R00@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Wed, 13 Feb 2008 16:26:45 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW700KDAD8L7Q80@fe-sfbay-09.sun.com>; Wed, 13 Feb 2008 16:26:45 -0800 (PST) Date: Wed, 13 Feb 2008 16:36:23 -0800 From: Phi Tran Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <47B38BEF.8040802@Sun.COM> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B38D07.6090207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802132315.m1DNFHKu008082@marduk.eng.sun.com> <47B3816E.3090705@Sun.COM> <47B38BEF.8040802@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 240 > The auditing of suspend is handled by the uadmin.c code. It creates an > audit record and the ends the auditing session before the actual This should say "it ends the auditing" not "the ends" like some bad movie. > suspend. > > Phi From randyf@jurassic.eng.sun.com Wed Feb 13 16:41:47 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1E0flwg015917 for ; Wed, 13 Feb 2008 16:41:47 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1E0fkD3001145; Wed, 13 Feb 2008 16:41:46 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW700K01DXLS400@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Feb 2008 16:41:45 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.104.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW7002LYDXLDG90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Feb 2008 16:41:45 -0800 (PST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id m1E0cuCe699454; Wed, 13 Feb 2008 16:38:57 -0800 (PST) Date: Wed, 13 Feb 2008 16:38:13 -0800 (PST) From: Randy Fishel Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: gww@eng.sun.com, Phi.Tran@sun.com Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Reply-to: Randy Fishel Message-id: <200802140038.m1E0cuCe699454@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_48 SunOS 5.10 sun4u sparc Content-type: text/PLAIN Content-transfer-encoding: 7BIT X-Sun-Text-type: ascii X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1302 > >> > >> Not really. When the kernel resumes, I would presume it stats > >> at the next kernel instruction following the instruction that > >> caused it to go into suspended animation. I would presume it > >> does not run genuinx:main() again that starts the system fresh > >> in a reboot, so I ask how is the resumed from suspended animation > >> audited? > >> > > > > I agree that any process resumed should start at the next instruction. > > > > As for the auditing of resume, I don't know how exactly it was done. > > I'll have to look up the bug and code that was integrated for this > > auditing. > > The auditing of suspend is handled by the uadmin.c code. It creates an > audit record and the ends the auditing session before the actual > suspend. > > Phi From what I remember, the team has agreed to do auditing either by direct code, or via commands that are known to audit (i.e. halt(1M), reboot(1M), uadmin(1M)). Failure to do it properly in HAL is a bug. Failure to do it properly in existing tools is a bug. It would have been far better to have just said "the project *will* audit and have review the changes", than to go through this round of question and requestion til the already known answer is returned. ---- Randy From gww@eng.sun.com Wed Feb 13 17:19:58 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1E1Jw15017057 for ; Wed, 13 Feb 2008 17:19:58 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1E1JvKE016384; Wed, 13 Feb 2008 17:19:57 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW700105FP97H00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Feb 2008 17:19:57 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW70024WFP9DLC0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Feb 2008 17:19:57 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1E1JuIQ033344; Wed, 13 Feb 2008 17:19:56 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1E1K84I008375; Wed, 13 Feb 2008 17:20:08 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1E1K77Y008374; Wed, 13 Feb 2008 17:20:07 -0800 (PST) Date: Wed, 13 Feb 2008 17:20:07 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: gww@eng.sun.com, Phi.Tran@sun.com, randyf@jurassic.eng.sun.com Cc: PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802140120.m1E1K77Y008374@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1504 > > >> Not really. When the kernel resumes, I would presume it stats > > >> at the next kernel instruction following the instruction that > > >> caused it to go into suspended animation. I would presume it > > >> does not run genuinx:main() again that starts the system fresh > > >> in a reboot, so I ask how is the resumed from suspended animation > > >> audited? > > >> > > > > > > I agree that any process resumed should start at the next instruction. > > > > > > As for the auditing of resume, I don't know how exactly it was done. > > > I'll have to look up the bug and code that was integrated for this > > > auditing. > > > > The auditing of suspend is handled by the uadmin.c code. It creates an > > audit record and the ends the auditing session before the actual > > suspend. > > > > Phi > > > From what I remember, the team has agreed to do auditing either by > direct code, or via commands that are known to audit (i.e. halt(1M), > reboot(1M), uadmin(1M)). Failure to do it properly in HAL is a bug. > Failure to do it properly in existing tools is a bug. The architectural point is how does the project team expect to meet the requirements? I don't believe existing interfaces implementations are sufficient. IMO this is not, the (non-existant) Audit project team will do it for us. This actually requires some architecture on resuming after suspended animation that I was guessing the project team hadn't yet considered or addressed. Gary.. From David.Chieu@sun.com Wed Feb 13 18:59:35 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1E2xY7V020890 for ; Wed, 13 Feb 2008 18:59:35 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1E2xWG6007233; Thu, 14 Feb 2008 10:59:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW700G01KB8SQ00@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Feb 2008 18:59:32 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW700FQDKB7CF10@nwk-avmta-2.sfbay.sun.com>; Wed, 13 Feb 2008 18:59:31 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1E2xVNA028103; Wed, 13 Feb 2008 18:59:31 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW700H01K4PP500@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM); Wed, 13 Feb 2008 18:59:31 -0800 (PST) Received: from [10.1.48.114] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW7004Z9KB6XF50@fe-sfbay-09.sun.com>; Wed, 13 Feb 2008 18:59:31 -0800 (PST) Date: Wed, 13 Feb 2008 19:00:03 -0800 From: David Chieu Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200802140120.m1E1K77Y008374@marduk.eng.sun.com> Sender: David.Chieu@sun.com To: Gary Winiger Cc: Phi.Tran@sun.com, randyf@jurassic.eng.sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B3AEB3.6080002@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802140120.m1E1K77Y008374@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1909 Gary Winiger wrote: >>>>> Not really. When the kernel resumes, I would presume it stats >>>>> at the next kernel instruction following the instruction that >>>>> caused it to go into suspended animation. I would presume it >>>>> does not run genuinx:main() again that starts the system fresh >>>>> in a reboot, so I ask how is the resumed from suspended animation >>>>> audited? >>>>> >>>>> >>>> I agree that any process resumed should start at the next instruction. >>>> >>>> As for the auditing of resume, I don't know how exactly it was done. >>>> I'll have to look up the bug and code that was integrated for this >>>> auditing. >>>> >>> The auditing of suspend is handled by the uadmin.c code. It creates an >>> audit record and the ends the auditing session before the actual >>> suspend. >>> >>> Phi >>> >> From what I remember, the team has agreed to do auditing either by >> direct code, or via commands that are known to audit (i.e. halt(1M), >> reboot(1M), uadmin(1M)). Failure to do it properly in HAL is a bug. >> Failure to do it properly in existing tools is a bug. >> > > The architectural point is how does the project team expect to > meet the requirements? I don't believe existing interfaces > implementations are sufficient. IMO this is not, the (non-existant) > Audit project team will do it for us. This actually requires some > architecture on resuming after suspended animation that I was > guessing the project team hadn't yet considered or addressed. > > Gary.. > The project team understands your concern and wishes to work with you privately since there are many unresolved issues still. We've already marked this case "waiting need spec" with no foreseeable timeout. Your concerns will be communicated and duly written with satisfactory answers of your standard in the case spec.txt. -- David Chieu From Darren.Moffat@sun.com Thu Feb 14 03:38:21 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1EBcKs2003513 for ; Thu, 14 Feb 2008 03:38:21 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1EBc51W017793; Thu, 14 Feb 2008 19:38:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW800J098BSQJ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Feb 2008 03:38:16 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW8009XJ8BRSFA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Feb 2008 03:38:16 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1EBcEGo017913; Thu, 14 Feb 2008 11:38:14 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW800I0182RFZ00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 14 Feb 2008 11:38:14 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW8008E28BM6E10@fe-emea-10.sun.com>; Thu, 14 Feb 2008 11:38:10 +0000 (GMT) Date: Thu, 14 Feb 2008 11:38:09 +0000 From: Darren J Moffat Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200802132315.m1DNFHKu008082@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: Phi.Tran@sun.com, tamarack-core@sun.com, PSARC-ext@sun.com, solaris-battery-team@sun.com, dchieu@sac.sfbay.sun.com, x86power-iteam@sun.com Message-id: <47B42821.9000905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802132315.m1DNFHKu008082@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 914 Gary Winiger wrote: >> The kernel was suspended, so on a resume like any suspended process >> would start running again. That's my simplified answer :), but the >> power management group would have more details if needed. > > Not really. When the kernel resumes, I would presume it stats > at the next kernel instruction following the instruction that > caused it to go into suspended animation. I would presume it > does not run genuinx:main() again that starts the system fresh > in a reboot, so I ask how is the resumed from suspended animation > audited? What has this got to do with *this* project ? This project isn't adding suspend/resume support that project has already been ARC approved and has integrated. This project is just using existing interfaces that the suspend/resume projects already export. For SPARC suspend support was added way back in Solaris 2.6. -- Darren J Moffat From gww@eng.sun.com Thu Feb 14 12:30:10 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1EKU93Y028205 for ; Thu, 14 Feb 2008 12:30:09 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1EKU6S4007863; Thu, 14 Feb 2008 13:30:09 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW800125WY8QT00@brm-avmta-1.central.sun.com>; Thu, 14 Feb 2008 13:30:08 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW800KWAWY6EH50@brm-avmta-1.central.sun.com>; Thu, 14 Feb 2008 13:30:06 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1EKU60J060777; Thu, 14 Feb 2008 12:30:06 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1EKUFMq010506; Thu, 14 Feb 2008 12:30:15 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1EKUFB9010505; Thu, 14 Feb 2008 12:30:15 -0800 (PST) Date: Thu, 14 Feb 2008 12:30:15 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: gww@eng.sun.com, David.Chieu@sun.com Cc: Phi.Tran@sun.com, randyf@jurassic.eng.sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802142030.m1EKUFB9010505@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1557 > > The architectural point is how does the project team expect to > > meet the requirements? I don't believe existing interfaces > > implementations are sufficient. IMO this is not, the (non-existant) > > Audit project team will do it for us. This actually requires some > > architecture on resuming after suspended animation that I was > > guessing the project team hadn't yet considered or addressed. > > > > Gary.. > > > The project team understands your concern and wishes to work with you > privately since there are many unresolved issues still. We've already > marked this case "waiting need spec" with no foreseeable timeout. Your > concerns will be communicated and duly written with satisfactory answers > of your standard in the case spec.txt. I understand it's waiting need spec -- for different reasons. My motivation for posting was to add to the new specs completeness for whatever audit architecture was needed. Darren says this has nothing to do with this project. I disagree, past ignorance in granting approvals with missing architecture should not be criteria for approving current projects once the past oversites are identified. As the this project team (the Power management team) and the Audit project team will need to cooperate on other parts of audit being directly introduced by this project, it is appropriate to extend this cooperation to resolve the past architectural oversites. IMO, they are likely to add very little additional project team work beyond fleshing out the ignorance. Gary.. From gdamore@sun.com Thu Feb 14 12:45:37 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1EKja13028920 for ; Thu, 14 Feb 2008 12:45:36 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1EKjUOM024502; Fri, 15 Feb 2008 04:45:35 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW800203XNYZB00@brm-avmta-1.central.sun.com>; Thu, 14 Feb 2008 13:45:34 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW800K8MXNXEL90@brm-avmta-1.central.sun.com>; Thu, 14 Feb 2008 13:45:33 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1EKjXJO027946; Thu, 14 Feb 2008 12:45:33 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW800601XC66500@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Thu, 14 Feb 2008 12:45:33 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW800KVMXNWM6F0@fe-sfbay-09.sun.com>; Thu, 14 Feb 2008 12:45:33 -0800 (PST) Date: Thu, 14 Feb 2008 12:44:11 -0800 From: "Garrett D'Amore" Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200802142030.m1EKUFB9010505@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, Phi.Tran@sun.com, randyf@jurassic.eng.sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B4A81B.3020706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802142030.m1EKUFB9010505@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2071 Gary Winiger wrote: >> > I understand it's waiting need spec -- for different reasons. > My motivation for posting was to add to the new specs completeness > for whatever audit architecture was needed. > Darren says this has nothing to do with this project. I disagree, > past ignorance in granting approvals with missing architecture > should not be criteria for approving current projects once the > past oversites are identified. > As the this project team (the Power management team) and the > Audit project team will need to cooperate on other parts of > audit being directly introduced by this project, it is appropriate > to extend this cooperation to resolve the past architectural > oversites. IMO, they are likely to add very little additional > project team work beyond fleshing out the ignorance. > Gary, I'm a little confused here. My understanding is that the project merely calls other components which (hopefully) take care of the auditing. The auditing needs to happen in the core bits (either commands, libraries, or kernel bits) -- i.e. it shouldn't matter whether the suspend is happening as a result of hald, a sysadmin manually typing uadmin, or some other process -- the audit still needs to occur. If the GPM project is going to just consume other software which properly handles auditing, apart from ensuring that the consumed bits actually *do* conform to auditing requirements, what else is there for this project to do? Do you believe that a different kind of audit trail should be recorded by this project than if, for example, the sysadmin just types the uadmin command with the magic number arguments? Now if it turns out that the various facilities which GPM makes use of *don't* do the necessary auditing, then I agree there is a problem. (In which case, architecturally, I think the right thing to do is file a bug -- and maybe an associated fasttrack or self-review case -- against those components, and note that the fix for said bug is just a pre-requisite for this project.) -- Garrett From gww@eng.sun.com Thu Feb 14 13:38:39 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1ELccEO004170 for ; Thu, 14 Feb 2008 13:38:38 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1ELcJBS021975; Thu, 14 Feb 2008 21:38:35 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW900H490482S00@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Feb 2008 13:38:33 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW900B330462E90@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Feb 2008 13:38:30 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1ELcUIC031616; Thu, 14 Feb 2008 13:38:30 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1ELcgps010838; Thu, 14 Feb 2008 13:38:42 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1ELcgwi010837; Thu, 14 Feb 2008 13:38:42 -0800 (PST) Date: Thu, 14 Feb 2008 13:38:42 -0800 (PST) From: Gary Winiger Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] To: gww@eng.sun.com, gdamore@sun.com Cc: David.Chieu@sun.com, Phi.Tran@sun.com, randyf@jurassic.eng.sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802142138.m1ELcgwi010837@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1714 > > audit being directly introduced by this project, it is appropriate > > to extend this cooperation to resolve the past architectural > > oversites. IMO, they are likely to add very little additional > > project team work beyond fleshing out the ignorance. > > > > Gary, > > I'm a little confused here. My understanding is that the project merely I can tell ;-) or is it ;-(? > Do you believe that a different kind of audit trail should be recorded > by this project than if, for example, the sysadmin just types the uadmin > command with the magic number arguments? This project makes new access control decisions (within hald). Those require new audit records (not a different type of audit trail). This project appears to call other interfaces that currently audit the system discontinuity, I believe they said halt(1M), uadmin(1M) and perhaps some others. I was asking: 1. if the architecure of this project assured that they were called in the proper audit context; 2. what the architecture was for auditing resumption after suspended animation (as I could find no evidence that it was presently being audited). > Now if it turns out that the various facilities which GPM makes use of > *don't* do the necessary auditing, then I agree there is a problem. (In > which case, architecturally, I think the right thing to do is file a bug > -- and maybe an associated fasttrack or self-review case -- against > those components, and note that the fix for said bug is just a > pre-requisite for this project.) No, filing bugs is not the architectural solution. Each project needs to satisfy the Solaris Audit Policy. This project is no exception. Gary.. From brian.cameron@sun.com Thu Feb 14 14:04:05 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1EM45rE005622 for ; Thu, 14 Feb 2008 14:04:05 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1EM427m028233; Thu, 14 Feb 2008 14:04:04 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW90080X1ARXP00@brm-avmta-1.central.sun.com>; Thu, 14 Feb 2008 15:04:03 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW9008T11AQBG20@brm-avmta-1.central.sun.com>; Thu, 14 Feb 2008 15:04:02 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1EM41dx004645; Thu, 14 Feb 2008 22:04:01 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW90060108RG200@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM); Thu, 14 Feb 2008 15:04:01 -0700 (MST) Received: from [192.168.1.64] ([189.137.195.67]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW9005JY1ALFU80@mail-amer.sun.com>; Thu, 14 Feb 2008 15:03:59 -0700 (MST) Date: Thu, 14 Feb 2008 16:03:59 -0600 From: Brian Cameron Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200802142138.m1ELcgwi010837@marduk.eng.sun.com> Sender: brian.cameron@sun.com To: Gary Winiger Cc: gdamore@sun.com, randyf@jurassic.eng.sun.com, dchieu@sac.sfbay.sun.com, x86power-iteam@sun.com, tamarack-core@sun.com, Phi.Tran@sun.com, PSARC-ext@sun.com, David.Chieu@sun.com, solaris-battery-team@sun.com Message-id: <47B4BACF.4080403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802142138.m1ELcgwi010837@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 843 Gary: >> Do you believe that a different kind of audit trail should be recorded >> by this project than if, for example, the sysadmin just types the uadmin >> command with the magic number arguments? > > This project makes new access control decisions (within hald). Are you referring to the usage of libpolkit by hald and consumed by GPM? If the GPM project were to take libpolkit out of the picture, and instead just call chkauthattr directly in each program that needs to know if the user has authorization, then would this simplify the overall architecture of GPM and make this case less controversial? If there is some value in using libpolkit as a wrapper for checking RBAC authorizations, then perhaps this could be discussed in a follow-up ARC case where it might be easier to focus on the issues specific to using it. Brian From gdamore@sun.com Thu Feb 14 14:17:40 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1EMHdam007248 for ; Thu, 14 Feb 2008 14:17:39 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1EMHbM7034708; Thu, 14 Feb 2008 15:17:39 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW900A011XE5K00@brm-avmta-1.central.sun.com>; Thu, 14 Feb 2008 15:17:38 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW9008C31XDBG80@brm-avmta-1.central.sun.com>; Thu, 14 Feb 2008 15:17:37 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1EMHbpH008984; Thu, 14 Feb 2008 14:17:37 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW900H011VLC700@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Thu, 14 Feb 2008 14:17:37 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW900DE51X3U2B0@fe-sfbay-09.sun.com>; Thu, 14 Feb 2008 14:17:27 -0800 (PST) Date: Thu, 14 Feb 2008 14:16:05 -0800 From: "Garrett D'Amore" Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <200802142138.m1ELcgwi010837@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, Phi.Tran@sun.com, randyf@jurassic.eng.sun.com, PSARC-ext@sun.com, dchieu@sac.sfbay.sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47B4BDA5.4000008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802142138.m1ELcgwi010837@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 1501 Gary Winiger wrote: >>> audit being directly introduced by this project, it is appropriate >>> to extend this cooperation to resolve the past architectural >>> oversites. IMO, they are likely to add very little additional >>> project team work beyond fleshing out the ignorance. >>> >>> >> Gary, >> >> I'm a little confused here. My understanding is that the project merely >> > > I can tell ;-) or is it ;-(? > > >> Do you believe that a different kind of audit trail should be recorded >> by this project than if, for example, the sysadmin just types the uadmin >> command with the magic number arguments? >> > > This project makes new access control decisions (within hald). > Those require new audit records (not a different type of audit > trail). This project appears to call other interfaces that > currently audit the system discontinuity, I believe they said > halt(1M), uadmin(1M) and perhaps some others. I was asking: > 1. if the architecure of this project assured that they > were called in the proper audit context; > 2. what the architecture was for auditing resumption after > suspended animation (as I could find no evidence that > it was presently being audited). > Thanks for clarifying this. IIUC, the key issue here is: This project makes new access control decisions (within hald). So its the decisions which need to be audited. Given that, I agree that the gap here needs to be closed. -- Garrett From Darren.Moffat@sun.com Fri Feb 15 03:11:52 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1FBBp2T001368 for ; Fri, 15 Feb 2008 03:11:52 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1FBBegk001662; Fri, 15 Feb 2008 11:11:50 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWA00I0X1RPJ000@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Feb 2008 03:11:49 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWA00F7N1RNOGA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Feb 2008 03:11:49 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1FBBlFI017237; Fri, 15 Feb 2008 11:11:47 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWA00G011NDCQ00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Fri, 15 Feb 2008 11:11:47 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWA00B9M1R19H10@fe-emea-09.sun.com>; Fri, 15 Feb 2008 11:11:27 +0000 (GMT) Date: Fri, 15 Feb 2008 11:11:25 +0000 From: Darren J Moffat Subject: Re: GNOME Power Management Support [PSARC/2008/021 FastTrack timeout 01/23/2008] In-reply-to: <47B4BDA5.4000008@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Gary Winiger , randyf@jurassic.eng.sun.com, dchieu@sac.sfbay.sun.com, x86power-iteam@sun.com, tamarack-core@sun.com, Phi.Tran@sun.com, PSARC-ext@sun.com, David.Chieu@sun.com, solaris-battery-team@sun.com Message-id: <47B5735D.7020008@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802142138.m1ELcgwi010837@marduk.eng.sun.com> <47B4BDA5.4000008@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 724 Garrett D'Amore wrote: > Thanks for clarifying this. IIUC, the key issue here is: > > This project makes new access control decisions (within hald). > > > So its the decisions which need to be audited. Given that, I agree > that the gap here needs to be closed. I agree with that, however there was discussion of the audit records written on resume. That has nothing to do with this case because nothing in this case is involved in the resume only in wither or not the suspend is to be allowed or not. It is the auditing of the resume I am saying is out of scope for this project and that this project should not be held responsible for fixing if it doesn't currently work as required. -- Darren J Moffat From Phi.Tran@sun.com Tue Feb 19 15:23:26 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1JNNQEL006580 for ; Tue, 19 Feb 2008 15:23:26 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1JNNOdI020457; Tue, 19 Feb 2008 23:23:25 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWI00709EAZM600@brm-avmta-1.central.sun.com>; Tue, 19 Feb 2008 16:23:23 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWI00C5WEAX5BF0@brm-avmta-1.central.sun.com>; Tue, 19 Feb 2008 16:23:21 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1JNNLC6013641; Tue, 19 Feb 2008 15:23:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWI00001EAGHO00@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Tue, 19 Feb 2008 15:23:21 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWI002KLEAXN1G0@fe-sfbay-09.sun.com>; Tue, 19 Feb 2008 15:23:21 -0800 (PST) Date: Tue, 19 Feb 2008 15:33:03 -0800 From: Phi Tran Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] In-reply-to: <479D6856.2020601@Sun.COM> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47BB672F.1000105@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_C5MJJhAdbaPtOaBo3KPqFQ)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200801280227.m0S2RrwO028057@marduk.eng.sun.com> <479D6856.2020601@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 3990 This is a multi-part message in MIME format. --Boundary_(ID_C5MJJhAdbaPtOaBo3KPqFQ) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Gary, I've enumerated issues in this spec.txt document to address your concerns. I hope to develop this document and add it to the materials of PSARC/2008/021 HAL Power Management Support. Also, I hope this document would be sufficent to move these power management cases forward. Please review. Phi --Boundary_(ID_C5MJJhAdbaPtOaBo3KPqFQ) Content-type: text/plain; name=spec.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=spec.txt Administration -------------- GPM sets defaults using GConf. GConf was introduced in LSARC/2002/146 Gnome 2.0 Configuration - GConf. GConf is a system for storing application preferences which would allow GPM to start according to a user's preference. Any changes that a user makes to the GPM graphical user interface preferences are stored in the GConf database and persists across reboots. GPM Defaults ------------ What happens on a freshly installed system with GPM? For any user who is logged into an X session, GPM will by default have these actions: Lid - When a user closes the lid, the system will by default suspend if supported. If suspend is not supported, the action will be to do nothing by default. One can change the default to blank screen or do nothing. Power button - Pressing the power button will by default open a GUI that allows the user to choose actions such as shutdown, suspend, or hibernate. One can change the default to immediately shutdown, suspend, or hibernate without a GUI prompt. Suspend and hibernate are only available if the system supports these actions. LCD Brightness - On AC power, there is no change in brightness. On battery power, the brightness reduces to 50% by default. One can adjust the default brightness level. Screen Lock - The screen will lock by default if the user returns from actions such as suspend, hibernate, or blank screen. This action can be disabled. CPU frequency - By default, there is no change in CPU frequency handling. One can change the default to either a "On Demand" or Performance governor. If no one is logged into an X session, the defaults above will be true except for the following: Lid - When a user closes the lid, the system will by default suspend if supported. If suspend is not supported, the action will be to do nothing by default. One can change the default to do nothing. Power button - Pressing the power button will by default shutdown the system. This default is not configurable. LCD Brightness - There is no change in brightness. This default is not configurable. Screen Lock - There is no screen lock action since no one is logged into an X session. Auditing -------- The project team will work with the audit team to enable auditing in accordance to the Solaris Auditing Policy. However, any issues with auditing in the current power management interfaces will be considered a bug. Security -------- The requirement is that we cannot have two security policies in Solaris so the security policy we implement will be RBAC. By porting any security policies to RBAC, we can then have one picture on how to administer the security policies. This requirement will allow one to only need the RBAC administration tools. PolicyKit is a security policy on Linux similar to RBAC. The plan has been to port the pieces that are needed into RBAC. libpolkit is a small piece of PolicyKit that has been ported to use RBAC since its introduction in PSARC/2005/399 Tamarack: Removable Media Enhancements. So far, projects will only port the piece of PolicyKit that is needed. What about the rest of PolicyKit? Any piece of PolicyKit used by a project team would be required to port to RBAC and thus keep with the requirement of having only one security policy and administration. --Boundary_(ID_C5MJJhAdbaPtOaBo3KPqFQ)-- From David.Chieu@sun.com Wed Feb 20 10:36:38 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KIac6M017925 for ; Wed, 20 Feb 2008 10:36:38 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1KIaahp013678; Wed, 20 Feb 2008 10:36:38 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWJ00707VP2F000@brm-avmta-1.central.sun.com>; Wed, 20 Feb 2008 11:36:38 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWJ00GB7VP1POE0@brm-avmta-1.central.sun.com>; Wed, 20 Feb 2008 11:36:37 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1KIabS0008355; Wed, 20 Feb 2008 10:36:37 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWJ00401VI9LX00@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM); Wed, 20 Feb 2008 10:36:37 -0800 (PST) Received: from [10.1.48.114] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ006H4VP0LZA0@fe-sfbay-09.sun.com>; Wed, 20 Feb 2008 10:36:37 -0800 (PST) Date: Wed, 20 Feb 2008 10:37:09 -0800 From: David Chieu Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 02/27/2008] In-reply-to: <47BB672F.1000105@Sun.COM> Sender: David.Chieu@sun.com To: Phi Tran Cc: Gary Winiger , psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47BC7355.4000106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200801280227.m0S2RrwO028057@marduk.eng.sun.com> <479D6856.2020601@Sun.COM> <47BB672F.1000105@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 403 FYI. I've reset the case timeout to 2/27/2008. -- David Chieu Phi Tran wrote: > Gary, > > I've enumerated issues in this spec.txt document to address your > concerns. I hope to develop this document and add it to the materials > of PSARC/2008/021 HAL Power Management Support. Also, I hope this > document would be sufficent to move these power management cases > forward. Please review. > > Phi From gww@eng.sun.com Wed Feb 20 10:39:40 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KIddnf017981 for ; Wed, 20 Feb 2008 10:39:39 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KId1eM024927; Wed, 20 Feb 2008 18:39:32 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWJ0040DVTR6800@nwk-avmta-2.sfbay.sun.com>; Wed, 20 Feb 2008 10:39:27 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWJ002F1VTPC420@nwk-avmta-2.sfbay.sun.com>; Wed, 20 Feb 2008 10:39:25 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KIdPwv040229; Wed, 20 Feb 2008 10:39:25 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1KIdlT3019319; Wed, 20 Feb 2008 10:39:47 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1KIdkct019318; Wed, 20 Feb 2008 10:39:46 -0800 (PST) Date: Wed, 20 Feb 2008 10:39:46 -0800 (PST) From: Gary Winiger Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 02/27/2008] To: Phi.Tran@sun.com, David.Chieu@sun.com Cc: gww@eng.sun.com, psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802201839.m1KIdkct019318@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 142 > FYI. I've reset the case timeout to 2/27/2008. Are the updated materials intended to include the Umbrella information asked for? Gary.. From Phi.Tran@sun.com Wed Feb 20 10:51:25 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KIpOYS018443 for ; Wed, 20 Feb 2008 10:51:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1KIpMEw026543; Wed, 20 Feb 2008 11:51:24 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWJ00F0LWDM3W00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 20 Feb 2008 10:51:22 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWJ00DT6WDLSM00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 20 Feb 2008 10:51:21 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1KIpLZG010685; Wed, 20 Feb 2008 10:51:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWJ00A01VGCTJ00@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Wed, 20 Feb 2008 10:51:21 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ007NJWDEUN30@fe-sfbay-10.sun.com>; Wed, 20 Feb 2008 10:51:14 -0800 (PST) Date: Wed, 20 Feb 2008 11:00:55 -0800 From: Phi Tran Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 02/27/2008] In-reply-to: <200802201839.m1KIdkct019318@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: David.Chieu@sun.com, psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47BC78E7.6010901@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802201839.m1KIdkct019318@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 348 Gary Winiger wrote: >>FYI. I've reset the case timeout to 2/27/2008. > > > Are the updated materials intended to include the Umbrella information > asked for? It is an umbrella that details issues that were brought up in previous emails and meetings with you. If there are specific information you think are missing, please identify. Phi From gww@eng.sun.com Wed Feb 20 11:10:30 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJAUtZ021011 for ; Wed, 20 Feb 2008 11:10:30 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1KJAQ2R007983; Wed, 20 Feb 2008 11:10:30 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWJ00915X9HXG00@brm-avmta-1.central.sun.com>; Wed, 20 Feb 2008 12:10:29 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWJ007GWX9EMIA0@brm-avmta-1.central.sun.com>; Wed, 20 Feb 2008 12:10:27 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KJAQrt063122; Wed, 20 Feb 2008 11:10:26 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1KJAmKO019413; Wed, 20 Feb 2008 11:10:48 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1KJAmBB019412; Wed, 20 Feb 2008 11:10:48 -0800 (PST) Date: Wed, 20 Feb 2008 11:10:48 -0800 (PST) From: Gary Winiger Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 02/27/2008] To: gww@eng.sun.com, Phi.Tran@sun.com Cc: David.Chieu@sun.com, psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802201910.m1KJAmBB019412@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 353 > > Are the updated materials intended to include the Umbrella information > > asked for? > > It is an umbrella that details issues that were brought up in previous > emails and meetings with you. If there are specific information you > think are missing, please identify. I was asking procedurally. I've not reviewed the updated spec. Gary.. From gww@eng.sun.com Wed Feb 20 14:52:35 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KMqY9n009932 for ; Wed, 20 Feb 2008 14:52:35 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1KMqX8E025548; Wed, 20 Feb 2008 15:52:34 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWK00E037JLP400@nwk-avmta-1.sfbay.Sun.COM>; Wed, 20 Feb 2008 14:52:33 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWK00DFJ7JLSPD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 20 Feb 2008 14:52:33 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KMqWpQ024428; Wed, 20 Feb 2008 14:52:32 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1KMqtOj020173; Wed, 20 Feb 2008 14:52:55 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1KMqtnS020172; Wed, 20 Feb 2008 14:52:55 -0800 (PST) Date: Wed, 20 Feb 2008 14:52:55 -0800 (PST) From: Gary Winiger Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 02/27/2008] To: Phi.Tran@sun.com, gww@eng.sun.com Cc: David.Chieu@sun.com, psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802202252.m1KMqtnS020172@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 710 > Gary Winiger wrote: > >>FYI. I've reset the case timeout to 2/27/2008. > > > > > > Are the updated materials intended to include the Umbrella information > > asked for? > > It is an umbrella that details issues that were brought up in previous > emails and meetings with you. If there are specific information you > think are missing, please identify. It does address a number of the issues I brought up, but unfortunately it's not the umbrella that I believe was requested. Other members is this the umbrella requested. I wasn't at the meeting, so I'm not sure how broad an umbrella was requested. This seems to address directly related questions. More on the update momentarially. Gary.. From gww@eng.sun.com Wed Feb 20 15:42:36 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KNgZFf013373 for ; Wed, 20 Feb 2008 15:42:35 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1KNgYbX015945; Wed, 20 Feb 2008 15:42:35 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWK00J0R9UYHF00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 20 Feb 2008 15:42:34 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWK00GAT9UXG020@nwk-avmta-1.sfbay.Sun.COM>; Wed, 20 Feb 2008 15:42:33 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KNgX5N056435; Wed, 20 Feb 2008 15:42:33 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1KNgt6U020500; Wed, 20 Feb 2008 15:42:55 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1KNgtGp020499; Wed, 20 Feb 2008 15:42:55 -0800 (PST) Date: Wed, 20 Feb 2008 15:42:55 -0800 (PST) From: Gary Winiger Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] To: Phi.Tran@sun.com, gww@eng.sun.com Cc: psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802202342.m1KNgtGp020499@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3000 > of PSARC/2008/021 HAL Power Management Support. Also, I hope this > document would be sufficent to move these power management cases > forward. That depends on the scope of the umbrella requested. This seems limited to the interaction between HAL PM support and the LSARC GPM case. > Please review. Below. Thanks for the additional information. As this may be a part of a continuing spec, I'll note some nits as well as questions still unresolved. > Administration > Any changes that a user makes to the GPM graphical user interface preferences > are stored in the GConf database and persists across reboots. Nit. I believe the intent here is to persist across login sessions, not just reboots. > GPM Defaults > For any user who is logged into an X session, GPM will by default > have these actions: How does this user get permission to do these actions? What happens if the user doesn't have permission? > If no one is logged into an X session, the defaults above will be true > except for the following: In some sense, how/when is this done? Upon initial system boot and at every logout? Is there a notification architecture for user logout? > Lid - When a user closes the lid, the system will by default suspend if > supported. If suspend is not supported, the action will be to do nothing > by default. One can change the default to do nothing. Who is the "One"? How does the "One" change things? Are these system wide defaults? Are there new /etc files? Are the defaults part of an SMF service? What service? ... > Auditing > in accordance to the Solaris Auditing Policy. However, any issues > with auditing in the current power management interfaces will be > considered a bug. I agree with it being an audit bug and have filed 6664265 uadmin(1M) auditing seems a mess What I was asking the team about was the architecture that was relevant to audit across a system discontinutity. It's neither self evident from this case, or uadmin(1M), or uadmin(2). I've also filed a man page bug 6664263 uadmin(2) is incomplete Reading over 1992/201, 1992/202, 1993/243, 1993/319, 1993/462, 1996/058, 1996/257, 1997/126, 1997/326, 2005/067 haven't filled in the gaps. Is there a suggestion where else to gleen the architecture? > Security > PolicyKit is a security policy on Linux similar to RBAC. The plan has > been to port the pieces that are needed into RBAC. libpolkit is a > small piece of PolicyKit that has been ported to use RBAC since its > introduction in PSARC/2005/399 Tamarack: Removable Media Enhancements. So > far, projects will only port the piece of PolicyKit that is needed. What > about the rest of PolicyKit? Any piece of PolicyKit used by a project team > would be required to port to RBAC and thus keep with the requirement > of having only one security policy and administration. I remain concerned with a piece meal approach without an umbrella to describe how/where the pieces fit together. Gary.. From Phi.Tran@sun.com Fri Feb 22 10:50:19 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1MIoJBY009826 for ; Fri, 22 Feb 2008 10:50:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1MIoIDs013191; Fri, 22 Feb 2008 10:50:19 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWN0040DLNUV800@brm-avmta-1.central.sun.com>; Fri, 22 Feb 2008 11:50:18 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWN009GOLNUZAD0@brm-avmta-1.central.sun.com>; Fri, 22 Feb 2008 11:50:18 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1MIoHRn006099; Fri, 22 Feb 2008 10:50:17 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWN00I01K5D5500@fe-sfbay-09.sun.com> (original mail from Phi.Tran@Sun.COM); Fri, 22 Feb 2008 10:50:17 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWN002X6LNNEI70@fe-sfbay-09.sun.com>; Fri, 22 Feb 2008 10:50:11 -0800 (PST) Date: Fri, 22 Feb 2008 10:59:53 -0800 From: Phi Tran Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] In-reply-to: <200802202342.m1KNgtGp020499@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47BF1BA9.3080800@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802202342.m1KNgtGp020499@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 4516 Gary Winiger wrote: >>of PSARC/2008/021 HAL Power Management Support. Also, I hope this >>document would be sufficent to move these power management cases >>forward. > > > That depends on the scope of the umbrella requested. This > seems limited to the interaction between HAL PM support > and the LSARC GPM case. Yes, this addresses specific issues that are clearly defined for HAL/GPM and which I believe will give sufficient information to move these cases forward. > > >> Please review. > > > Below. Thanks for the additional information. As this may > be a part of a continuing spec, I'll note some nits as well > as questions still unresolved. > > >>Administration > > >>Any changes that a user makes to the GPM graphical user interface preferences >>are stored in the GConf database and persists across reboots. > > > Nit. I believe the intent here is to persist across login > sessions, not just reboots. > Agreed. I'll replace reboots with logins. > >>GPM Defaults > > >>For any user who is logged into an X session, GPM will by default >>have these actions: > > > How does this user get permission to do these actions? The user will get permission by having the correct RBAC authorization as described in this case. > What happens if the user doesn't have permission? > The GPM GUI will not show options that are not authorized for the user. > >>If no one is logged into an X session, the defaults above will be true >>except for the following: > > > In some sense, how/when is this done? Upon initial system boot > and at every logout? Is there a notification architecture for > user logout? Yes, these defaults are set upon initial system boot and at every logout. There is no existing notification architecture for logout. A sysevent will need to be generated at console logout. > > >>Lid - When a user closes the lid, the system will by default suspend if >>supported. If suspend is not supported, the action will be to do nothing >>by default. One can change the default to do nothing. > > > Who is the "One"? How does the "One" change things? > Are these system wide defaults? Are there new /etc files? > Are the defaults part of an SMF service? What service? ... When no one is logged in, "One" means root. A root user would have to log in and use the GPM GUI to change the defaults. GConf has a system wide repository in /etc/gconf. The GPM system wide defaults are stored here. The GPM defaults for any user are stored in $HOME/.gconf. AFAIK, there is no SMF service associated with GConf, but is managed by the /usr/lib/gconfd-2 daemon. > > >>Auditing > > >>in accordance to the Solaris Auditing Policy. However, any issues >>with auditing in the current power management interfaces will be >>considered a bug. > > > I agree with it being an audit bug and have filed > 6664265 uadmin(1M) auditing seems a mess > > What I was asking the team about was the architecture that was > relevant to audit across a system discontinutity. It's neither > self evident from this case, or uadmin(1M), or uadmin(2). > I've also filed a man page bug 6664263 uadmin(2) is incomplete > > Reading over 1992/201, 1992/202, 1993/243, 1993/319, 1993/462, > 1996/058, 1996/257, 1997/126, 1997/326, 2005/067 haven't filled > in the gaps. > > Is there a suggestion where else to gleen the architecture? > > >>Security > > >>PolicyKit is a security policy on Linux similar to RBAC. The plan has >>been to port the pieces that are needed into RBAC. libpolkit is a >>small piece of PolicyKit that has been ported to use RBAC since its >>introduction in PSARC/2005/399 Tamarack: Removable Media Enhancements. So >>far, projects will only port the piece of PolicyKit that is needed. What >>about the rest of PolicyKit? Any piece of PolicyKit used by a project team >>would be required to port to RBAC and thus keep with the requirement >>of having only one security policy and administration. > > > I remain concerned with a piece meal approach without an umbrella > to describe how/where the pieces fit together. A PolicyKit umbrella is not trivial and it would be a surprise requirement due to the precedent case. These new HAL and GPM cases do not actually rely on PolicyKit so there is no need for an umbrella from these case. libpolkit maps Linux privileges to RBAC and even this can be removed since it will be easy to use the correct RBAC authorization without needing an explicit mapping. Phi From randy.fishel@sun.com Mon Feb 25 22:31:37 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1Q6Vbju015367 for ; Mon, 25 Feb 2008 22:31:37 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1Q6VaDJ024529; Mon, 25 Feb 2008 22:31:37 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWU00I0724NW500@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 22:31:35 -0800 (PST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWU00GU524MGH30@nwk-avmta-1.sfbay.Sun.COM>; Mon, 25 Feb 2008 22:31:34 -0800 (PST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1Q6VYPU000327; Mon, 25 Feb 2008 22:31:34 -0800 (PST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id m1Q6UiG7013031; Mon, 25 Feb 2008 22:30:44 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id m1Q6Uivx013027; Mon, 25 Feb 2008 22:30:44 -0800 (PST) Date: Mon, 25 Feb 2008 22:30:43 -0800 (PST) From: Randy Fishel Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 02/27/2008] In-reply-to: <200802201839.m1KIdkct019318@marduk.eng.sun.com> X-X-Sender: randyf@grimmy To: Gary Winiger Cc: Phi.Tran@sun.com, David.Chieu@sun.com, psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802201839.m1KIdkct019318@marduk.eng.sun.com> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 2372 On Wed, 20 Feb 2008, Gary Winiger wrote: > > FYI. I've reset the case timeout to 2/27/2008. > > Are the updated materials intended to include the Umbrella information > asked for? > > Gary.. > This case does not include the requested Umbrella. The primary reason is that the requested umbrella: the Power Management big picture, to be sufficiently complete is a large non-trivial endeavor that will take some time to generate, and should include far more than is needed to understand this case. There have been some suggestions for reducing the scope, but most of these suggestions would either generate questions on items not included, or would provide little new or useful information. I do agree that a picture/strategey/architecture needs to be generated, and several people are working on generating appropriate documents that will be provided for future PSARC review (meaning: there is a formal "promise" by more than one person, including management, that this document is coming, and not just because the ARC's have asked, but because the teams involved believe it is necessary to correctly scope the work). We believe, though, that this case "HAL Power Management Support" will comply with that "big picture" once complete, as the scope of _this_ case is limited to a small set of power management features (specifically suspend/resume, laptop lid controls, and display brightness controls) and meets Solaris Power Management requirements: It will use *existing committed* Solaris API's, such as uadmin(1m) and rbac(5) (chkauthattr(3secdb)/getauthattr(3secdb)). Should the underlying mechanisms change, they should be transparent to HAL, and then effectively be transparent to the end user. It is extensible. If new API's are required, they can be easily added to HAL, or even change in HAL so that the end user experience remains consistant as the architecture evolves. It acts as an agent to GNOME utilities, so that any tools that come from the GNOME community will have the desired Solaris behavior and use desired Solaris API's with little or no modification to GNOME tools. This is important as we also desire that tools not provided in Solaris or tools that are installed or compiled after installation also get proper Solaris behavior. ---- Randy From gww@eng.sun.com Tue Feb 26 23:08:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1R7801i000707 for ; Tue, 26 Feb 2008 23:08:01 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1R77uC4027323; Wed, 27 Feb 2008 15:07:59 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWV0000BYHAGH00@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 00:07:58 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWV00ME6YH9VN00@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 00:07:57 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1R77vum055572; Tue, 26 Feb 2008 23:07:57 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1R78S65000449; Tue, 26 Feb 2008 23:08:28 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1R78SNV000448; Tue, 26 Feb 2008 23:08:28 -0800 (PST) Date: Tue, 26 Feb 2008 23:08:28 -0800 (PST) From: Gary Winiger Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] To: Phi.Tran@sun.com, gww@eng.sun.com Cc: psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <200802270708.m1R78SNV000448@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5364 > > That depends on the scope of the umbrella requested. This > > seems limited to the interaction between HAL PM support > > and the LSARC GPM case. > > Yes, this addresses specific issues that are clearly defined for HAL/GPM > and which I believe will give sufficient information to move these > cases forward. After agreement on Randy's posting, but not from your's. > >>GPM Defaults > > > > > >>For any user who is logged into an X session, GPM will by default > >>have these actions: > > > > > > How does this user get permission to do these actions? > > The user will get permission by having the correct RBAC authorization > as described in this case. So a user's defaults are ignored at login if the user doesn't have appropriate authorization? How does the user figure this out? And how does the user get appropriate authorization? Where are the administative steps defined/documented. I.e., what's the user and administrator experience? (Bob Hagmann memorial question) > > What happens if the user doesn't have permission? > > > > The GPM GUI will not show options that are not authorized for the user. That's fine for showing what can be changed, but doesn't do much for setting the user's defaults. Viz a shared home directory. > >>If no one is logged into an X session, the defaults above will be true > >>except for the following: > > > > > > In some sense, how/when is this done? Upon initial system boot > > and at every logout? Is there a notification architecture for > > user logout? > > Yes, these defaults are set upon initial system boot and at every > logout. There is no existing notification architecture for logout. > A sysevent will need to be generated at console logout. Please say more about recognizing console logout. Is this project defining a new sysevent? What's the architecture for sending that event? > >>Lid - When a user closes the lid, the system will by default suspend if > >>supported. If suspend is not supported, the action will be to do nothing > >>by default. One can change the default to do nothing. > > > > > > Who is the "One"? How does the "One" change things? > > Are these system wide defaults? Are there new /etc files? > > Are the defaults part of an SMF service? What service? ... > > When no one is logged in, "One" means root. A root user would have to > log in and use the GPM GUI to change the defaults. > > GConf has a system wide repository in /etc/gconf. The GPM system wide > defaults are stored here. The GPM defaults for any user are stored in > $HOME/.gconf. AFAIK, there is no SMF service associated with GConf, but > is managed by the /usr/lib/gconfd-2 daemon. So your saying only root can administer /etc/gconf GPM defaults? Why should that be so? Why shouldn't a properly authorized user/role be able to modify the system defaults? Perhaps I'm getting into the LSARC case, but these are really Siamese twins that need an overarching architecture before they can be separated. Perhaps this calls into the entire GNOME administrative architecture. I'm not suggesting this project is responsible for that architecture, but does point out the that I don't know where to find it to ensure it meets the various Solaris Policies. > >>Auditing > > What I was asking the team about was the architecture that was > > relevant to audit across a system discontinutity. It's neither > > self evident from this case, or uadmin(1M), or uadmin(2). > > I've also filed a man page bug 6664263 uadmin(2) is incomplete > > > > Reading over 1992/201, 1992/202, 1993/243, 1993/319, 1993/462, > > 1996/058, 1996/257, 1997/126, 1997/326, 2005/067 haven't filled > > in the gaps. > > > > Is there a suggestion where else to gleen the architecture? Any thoughts?? > >>Security > > > > > >>PolicyKit is a security policy on Linux similar to RBAC. The plan has > >>been to port the pieces that are needed into RBAC. libpolkit is a > >>small piece of PolicyKit that has been ported to use RBAC since its > >>introduction in PSARC/2005/399 Tamarack: Removable Media Enhancements. So > >>far, projects will only port the piece of PolicyKit that is needed. What > >>about the rest of PolicyKit? Any piece of PolicyKit used by a project team > >>would be required to port to RBAC and thus keep with the requirement > >>of having only one security policy and administration. > > > > > > I remain concerned with a piece meal approach without an umbrella > > to describe how/where the pieces fit together. > > A PolicyKit umbrella is not trivial and it would be a surprise > requirement due to the precedent case. I don't follow what you're saying. I read you comment as saying this project (and hinting others) well be taking parts of PolicyKit into Solaris. Without some review if PolicyKit how can the architecure of the parts be viewed as correct? > These new HAL and GPM cases do not actually rely on PolicyKit so there > is no need for an umbrella from these case. libpolkit maps Linux > privileges to RBAC and even this can be removed since it will be easy to > use the correct RBAC authorization without needing an explicit mapping. If you remove libpolkit what are the side consequences? I'm not suggesting it be removed, just a lack of knowing where the ARC case that reviewed it. Gary.. From randy.fishel@sun.com Wed Feb 27 01:19:58 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1R9JvMP004603 for ; Wed, 27 Feb 2008 01:19:57 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1R9JvcX028453; Wed, 27 Feb 2008 02:19:57 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWW00B094L98200@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 02:19:57 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWW00MPN4L8VIA0@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 02:19:56 -0700 (MST) Received: from grimmy.eng.sun.com (grimmy.SFBay.Sun.COM [129.146.108.114]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1R9JtP4060400; Wed, 27 Feb 2008 01:19:55 -0800 (PST) Received: from grimmy.eng.sun.com (localhost [127.0.0.1]) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id m1R9J5G7027329; Wed, 27 Feb 2008 01:19:05 -0800 (PST) Received: from localhost (randyf@localhost) by grimmy.eng.sun.com (8.12.10+Sun/8.12.10/Submit) with ESMTP id m1R9J4XP027325; Wed, 27 Feb 2008 01:19:04 -0800 (PST) Date: Wed, 27 Feb 2008 01:19:04 -0800 (PST) From: Randy Fishel Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] In-reply-to: <200802270708.m1R78SNV000448@marduk.eng.sun.com> X-X-Sender: randyf@grimmy To: Gary Winiger Cc: Phi.Tran@sun.com, psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802270708.m1R78SNV000448@marduk.eng.sun.com> X-Authentication-warning: grimmy.eng.sun.com: randyf owned process doing -bs Status: RO Content-Length: 9772 > > > > > >>For any user who is logged into an X session, GPM will by default > > >>have these actions: > > > > > > > > > How does this user get permission to do these actions? > > > > The user will get permission by having the correct RBAC authorization > > as described in this case. > > So a user's defaults are ignored at login if the user doesn't > have appropriate authorization? The "users's defaults" will also be ignored if the underlying feature doesn't exist or isn't supported on the particular platform. In fact, as the discussion in this case seems to be primarily directed towards the suspend/resume feature, it should be noted that closing the lid on a laptop running Solaris will currently result in nothing happening (except a screen blank) as today, there is not a laptop that is supported for suspend and resume. And even if there were, there is no guarantee that the machine would actually suspend if asked due to the myriad of non-PM code that can cause a suspend to fail. It is also possible that "defaults" could be different on various platforms (authorizations and/or PM actions), or maybe defined by a systems adminstrator. So there are plenty of proper methods by which a user would get "defaults" that are "different" than expected. But these are all policy decisions, the arcitecture is to provide a way to have and implement policies. > How does the user figure this > out? And how does the user get appropriate authorization? > Where are the administative steps defined/documented. I.e., > what's the user and administrator experience? (Bob Hagmann > memorial question) Authorizations come from RBAC, so they would use those defined and documented steps and tools, and have that user and administrator experience. > > > > What happens if the user doesn't have permission? > > > > > > > The GPM GUI will not show options that are not authorized for the user. > > That's fine for showing what can be changed, but doesn't do > much for setting the user's defaults. Viz a shared home directory. We can rathole on the authorization (and audit) questions for a long time. But are the questions and answers really different than any other case, or maybe are they really implementation details? > > > >>If no one is logged into an X session, the defaults above will be true > > >>except for the following: > > > > > > > > > In some sense, how/when is this done? Upon initial system boot > > > and at every logout? Is there a notification architecture for > > > user logout? > > > > Yes, these defaults are set upon initial system boot and at every > > logout. There is no existing notification architecture for logout. > > A sysevent will need to be generated at console logout. > > Please say more about recognizing console logout. Is this > project defining a new sysevent? What's the architecture > for sending that event? > Phi can (and should) answer better, but I believe this intent was to provide a mechanism for some action when there is no user logged in. And my understanding was to describe that there may need to be some work to have HAL be notified of the event that a GNOME user has logged out, not that a new Solaris notification needs be added. > > >>Lid - When a user closes the lid, the system will by default suspend if > > >>supported. If suspend is not supported, the action will be to do nothing > > >>by default. One can change the default to do nothing. > > > > > > > > > Who is the "One"? How does the "One" change things? > > > Are these system wide defaults? Are there new /etc files? > > > Are the defaults part of an SMF service? What service? ... > > > > When no one is logged in, "One" means root. A root user would have to > > log in and use the GPM GUI to change the defaults. > > > > GConf has a system wide repository in /etc/gconf. The GPM system wide > > defaults are stored here. The GPM defaults for any user are stored in > > $HOME/.gconf. AFAIK, there is no SMF service associated with GConf, but > > is managed by the /usr/lib/gconfd-2 daemon. > > So your saying only root can administer /etc/gconf GPM defaults? > Why should that be so? Why shouldn't a properly authorized > user/role be able to modify the system defaults? > > Perhaps I'm getting into the LSARC case, but these are really > Siamese twins that need an overarching architecture before they > can be separated. Perhaps this calls into the entire GNOME > administrative architecture. I'm not suggesting this project > is responsible for that architecture, but does point out the > that I don't know where to find it to ensure it meets the various > Solaris Policies. Yes, this is more in line with the LSARC case, as this is the primary UI. But even there, "defaults" are a policy decision, and not really architecture. Not wanting to polute this case any more than necessary, but IMHO these particular defaults should be defined to *NOT* suspend on a lid close, as at this time I don't want any user to believe that his machine will definitely suspend if they close the lid, but instead require that they actually hit a "Suspend" button and physically verify that the machine suspended before closing the lid. At some time in the future, when there are more compliant drivers, code that prevents suspend is cleaned up, and the majority of platforms _will_ suspend, we can change the default. > > > >>Auditing > > > > What I was asking the team about was the architecture that was > > > relevant to audit across a system discontinutity. It's neither > > > self evident from this case, or uadmin(1M), or uadmin(2). > > > I've also filed a man page bug 6664263 uadmin(2) is incomplete uadmin(1M)/uadmin(2) is out of the scope of this case, as this case only involks these Solaris commands/tools that cause the discontinuity, and the brokeness (which, incidentally, has been there for *many* years) is in these utilities. > > > > > > Reading over 1992/201, 1992/202, 1993/243, 1993/319, 1993/462, > > > 1996/058, 1996/257, 1997/126, 1997/326, 2005/067 haven't filled > > > in the gaps. > > > > > > Is there a suggestion where else to gleen the architecture? > > Any thoughts?? None of the above cases will be usefull in understanding GNOME Power Manager or HAL, as (IIRC) they are all core power management cases (initial suspend/resume, some configuration follow-on, CPUPM, etc.), none of which are referenced in the initial case, nor are they relevant to any extent outside of any committed API's they define that might be consumed by HAL. Any questions/issues with uadmin should be taken offline (and probably with x86power-iteam@sun.com). The Tamarack, D-BUS, Battery and CPFreq cases will provide a better understanding to HAL, and all have diagrams that show how GNOME utilities (including GPM) interface to HAL and to Solaris (I think even the GPM case has a diagram of the GNOME/HAL/Solaris relationship). These cases are: PSARC/2005/399 Tamarack: Removable Media Enhancements in Solaris PSARC/2007/679 CPUFreq HAL PSARC/2006/601 Battery Project LSARC/2006/368 D-BUS Message Bus System LSARC/2007/702 Gnome Power Manager > > > >>Security > > > > > > > > >>PolicyKit is a security policy on Linux similar to RBAC. The plan has > > >>been to port the pieces that are needed into RBAC. libpolkit is a > > >>small piece of PolicyKit that has been ported to use RBAC since its > > >>introduction in PSARC/2005/399 Tamarack: Removable Media Enhancements. So > > >>far, projects will only port the piece of PolicyKit that is needed. What > > >>about the rest of PolicyKit? Any piece of PolicyKit used by a project team > > >>would be required to port to RBAC and thus keep with the requirement > > >>of having only one security policy and administration. > > > > > > > > > I remain concerned with a piece meal approach without an umbrella > > > to describe how/where the pieces fit together. > > > > A PolicyKit umbrella is not trivial and it would be a surprise > > requirement due to the precedent case. > > I don't follow what you're saying. I read you comment as saying > this project (and hinting others) well be taking parts of PolicyKit > into Solaris. Without some review if PolicyKit how can the > architecure of the parts be viewed as correct? I think there is definitely a hint that there needs to be a better understanding of the impending PolicyKit/RBAC collision. I also believe that this investigation is best undertaken proactively by the security group, as they are far more the experts in RBAC *and* security, and are better suited to understand how to manage the collision. This case is *only* adding a few more translations to those previously defined in Tamarack (and maybe CPUFreq). > > > These new HAL and GPM cases do not actually rely on PolicyKit so there > > is no need for an umbrella from these case. libpolkit maps Linux > > privileges to RBAC and even this can be removed since it will be easy to > > use the correct RBAC authorization without needing an explicit mapping. > > If you remove libpolkit what are the side consequences? > I'm not suggesting it be removed, just a lack of knowing > where the ARC case that reviewed it. I believe that this was suggested, as libpolkit and other security concerns (and not power management, I might add) have dominated the discussion, and there was at least one person who suggested that removing it would terminate the contention. IMO, at best this would only move the contention, and delay the inevitable (sooner or later Solaris Security will need to address PolicyKit issues). ---- Randy > > Gary.. > From Phi.Tran@sun.com Wed Feb 27 05:24:50 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RDOoRj011121 for ; Wed, 27 Feb 2008 05:24:50 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1RDOoXF018384; Wed, 27 Feb 2008 05:24:50 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWW00203FXCSJ00@nwk-avmta-2.sfbay.sun.com>; Wed, 27 Feb 2008 05:24:48 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWW00K4ZFXB3W60@nwk-avmta-2.sfbay.sun.com>; Wed, 27 Feb 2008 05:24:48 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1RDOlKI014745; Wed, 27 Feb 2008 05:24:47 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWW00601FQNSF00@fe-sfbay-10.sun.com> (original mail from Phi.Tran@Sun.COM); Wed, 27 Feb 2008 05:24:47 -0800 (PST) Received: from [10.1.49.220] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWW00JYSFXB5Z40@fe-sfbay-10.sun.com>; Wed, 27 Feb 2008 05:24:47 -0800 (PST) Date: Wed, 27 Feb 2008 05:34:31 -0800 From: Phi Tran Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 01/30/2008] In-reply-to: <200802270708.m1R78SNV000448@marduk.eng.sun.com> Sender: Phi.Tran@sun.com To: Gary Winiger Cc: psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com Message-id: <47C566E7.9040306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200802270708.m1R78SNV000448@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20060417 Status: RO Content-Length: 7068 Gary Winiger wrote: >>> That depends on the scope of the umbrella requested. This >>> seems limited to the interaction between HAL PM support >>> and the LSARC GPM case. >> >>Yes, this addresses specific issues that are clearly defined for HAL/GPM >>and which I believe will give sufficient information to move these >>cases forward. > > > After agreement on Randy's posting, but not from your's. > > >>>>GPM Defaults >>> >>> >>>>For any user who is logged into an X session, GPM will by default >>>>have these actions: >>> >>> >>> How does this user get permission to do these actions? >> >>The user will get permission by having the correct RBAC authorization >>as described in this case. > > > So a user's defaults are ignored at login if the user doesn't > have appropriate authorization? How does the user figure this > out? And how does the user get appropriate authorization? > Where are the administative steps defined/documented. I.e., > what's the user and administrator experience? (Bob Hagmann > memorial question) The only users allowed to use GPM are root and console owner which will be the Workstation Owner. On initial install, all console owners and root will have permission. The only reason a console owner will not have permission is if the administrator removes their authorization. The plan would be to document the administrative steps for power mgmt RBAC in the admin guide or what's new guide. > > >>> What happens if the user doesn't have permission? >>> >> >>The GPM GUI will not show options that are not authorized for the user. > > > That's fine for showing what can be changed, but doesn't do > much for setting the user's defaults. Viz a shared home directory. > > >>>>If no one is logged into an X session, the defaults above will be true >>>>except for the following: >>> >>> >>> In some sense, how/when is this done? Upon initial system boot >>> and at every logout? Is there a notification architecture for >>> user logout? >> >>Yes, these defaults are set upon initial system boot and at every >>logout. There is no existing notification architecture for logout. >>A sysevent will need to be generated at console logout. > > > Please say more about recognizing console logout. Is this > project defining a new sysevent? What's the architecture > for sending that event? A new sysevent would be generated in dtlogin and gdm at the time of console logout. Implementation-wise, the sysevent could be generated near or inside di_devperm_logout() in dtlogin, but I don't think gdm uses this call. > > >>>>Lid - When a user closes the lid, the system will by default suspend if >>>>supported. If suspend is not supported, the action will be to do nothing >>>>by default. One can change the default to do nothing. >>> >>> >>> Who is the "One"? How does the "One" change things? >>> Are these system wide defaults? Are there new /etc files? >>> Are the defaults part of an SMF service? What service? ... >> >>When no one is logged in, "One" means root. A root user would have to >>log in and use the GPM GUI to change the defaults. >> >>GConf has a system wide repository in /etc/gconf. The GPM system wide >>defaults are stored here. The GPM defaults for any user are stored in >>$HOME/.gconf. AFAIK, there is no SMF service associated with GConf, but >>is managed by the /usr/lib/gconfd-2 daemon. > > > So your saying only root can administer /etc/gconf GPM defaults? > Why should that be so? Why shouldn't a properly authorized > user/role be able to modify the system defaults? GPM uses GConf which only allows the database owner to change the files. Also, I don't see why GPM policy couldn't require only root to modify root files. > > Perhaps I'm getting into the LSARC case, but these are really > Siamese twins that need an overarching architecture before they > can be separated. Perhaps this calls into the entire GNOME > administrative architecture. I'm not suggesting this project > is responsible for that architecture, but does point out the > that I don't know where to find it to ensure it meets the various > Solaris Policies. > > >>>>Auditing > > >>> What I was asking the team about was the architecture that was >>> relevant to audit across a system discontinutity. It's neither >>> self evident from this case, or uadmin(1M), or uadmin(2). >>> I've also filed a man page bug 6664263 uadmin(2) is incomplete >>> >>> Reading over 1992/201, 1992/202, 1993/243, 1993/319, 1993/462, >>> 1996/058, 1996/257, 1997/126, 1997/326, 2005/067 haven't filled >>> in the gaps. >>> >>> Is there a suggestion where else to gleen the architecture? > > > Any thoughts?? I was leaving this question for the power mgmt team as part of the resolution on the bugs you filed. I don't have much insight on this issue (I'm not part of the power mgmt team). > > >>>>Security >>> >>> >>>>PolicyKit is a security policy on Linux similar to RBAC. The plan has >>>>been to port the pieces that are needed into RBAC. libpolkit is a >>>>small piece of PolicyKit that has been ported to use RBAC since its >>>>introduction in PSARC/2005/399 Tamarack: Removable Media Enhancements. So >>>>far, projects will only port the piece of PolicyKit that is needed. What >>>>about the rest of PolicyKit? Any piece of PolicyKit used by a project team >>>>would be required to port to RBAC and thus keep with the requirement >>>>of having only one security policy and administration. >>> >>> >>> I remain concerned with a piece meal approach without an umbrella >>> to describe how/where the pieces fit together. >> >>A PolicyKit umbrella is not trivial and it would be a surprise >>requirement due to the precedent case. > > > I don't follow what you're saying. I read you comment as saying > this project (and hinting others) well be taking parts of PolicyKit > into Solaris. Without some review if PolicyKit how can the > architecure of the parts be viewed as correct? The port for libpolkit does the following in pseudo code: if (hal-power-shutdown) { authname = "solaris.system.shutdown"; } chkauthattr(authname); where hal-power-shutdown is the Linux privilege. Yes, this can be called a port, but it should not be considered PolicyKit. My statement is a generalization for projects, but you can see what HAL does right now really doesn't depend on PolicyKit. > > >>These new HAL and GPM cases do not actually rely on PolicyKit so there >>is no need for an umbrella from these case. libpolkit maps Linux >>privileges to RBAC and even this can be removed since it will be easy to >>use the correct RBAC authorization without needing an explicit mapping. > > > If you remove libpolkit what are the side consequences? > I'm not suggesting it be removed, just a lack of knowing > where the ARC case that reviewed it. The libpolkit interface would need to be replaced since some programs depend on it from gnome and HAL. libpolkit was approved in the PSARC/2005/399 Tamarack case which I thought you were the PSARC sponsor? Phi From David.Chieu@sun.com Wed Feb 27 11:56:35 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RJuZBU028601 for ; Wed, 27 Feb 2008 11:56:35 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1RJuVup028616; Wed, 27 Feb 2008 19:56:32 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWW00I0FY27AZ00@nwk-avmta-2.sfbay.sun.com>; Wed, 27 Feb 2008 11:56:31 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWW00HW6Y26L800@nwk-avmta-2.sfbay.sun.com>; Wed, 27 Feb 2008 11:56:30 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1RJuUI8006897; Wed, 27 Feb 2008 11:56:30 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWW00L01XZRH000@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM); Wed, 27 Feb 2008 11:56:30 -0800 (PST) Received: from [10.1.48.114] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWW009VNY251ZE0@fe-sfbay-10.sun.com>; Wed, 27 Feb 2008 11:56:29 -0800 (PST) Date: Wed, 27 Feb 2008 11:57:04 -0800 From: David Chieu Subject: Gary please Approve or Derail PSARC 2008/021? In-reply-to: <47C566E7.9040306@Sun.COM> Sender: David.Chieu@sun.com To: Gary Winiger Cc: Phi Tran , psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com, Randy Fishel Message-id: <47C5C090.6000401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802270708.m1R78SNV000448@marduk.eng.sun.com> <47C566E7.9040306@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 559 Gary, Per PSARC meeting today, the ARC asked a closure of this case in which you are the named arbiter. We've learned a lot from your comments and because of your pointers we've improved our architecture based upon your guidance, especially in the security area. However, the case lasted longer than any us of wanted as a FastTrack. So, please answer with an approval (I know, with strings attached) or derail this case and help us out as a full case sponsor. Either way, we sincerely thank you for all the efforts and contributions. -- David Chieu From gdamore@sun.com Wed Feb 27 12:53:11 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RKrBGv001149 for ; Wed, 27 Feb 2008 12:53:11 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1RKr9Fs039492; Wed, 27 Feb 2008 13:53:10 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX00I090OKA300@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 13:53:08 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX00CKS0OIWW50@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 13:53:06 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1RKr6xp000925; Wed, 27 Feb 2008 12:53:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWX00M010ANTE00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Wed, 27 Feb 2008 12:53:06 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWX00B9Z0OH7L90@fe-sfbay-09.sun.com>; Wed, 27 Feb 2008 12:53:05 -0800 (PST) Date: Wed, 27 Feb 2008 12:51:12 -0800 From: "Garrett D'Amore" Subject: Re: Gary please Approve or Derail PSARC 2008/021? In-reply-to: <47C5C090.6000401@sun.com> Sender: Garrett.Damore@sun.com To: David Chieu Cc: Gary Winiger , Phi Tran , psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com, Randy Fishel Message-id: <47C5CD40.6090605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802270708.m1R78SNV000448@marduk.eng.sun.com> <47C566E7.9040306@Sun.COM> <47C5C090.6000401@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 858 David Chieu wrote: > Gary, > > Per PSARC meeting today, the ARC asked a closure of this case in which > you are the named arbiter. We've learned a lot from your comments and > because of your pointers we've improved our architecture based upon > your guidance, especially in the security area. However, the case > lasted longer than any us of wanted as a FastTrack. So, please answer > with an approval (I know, with strings attached) or derail this case > and help us out as a full case sponsor. Either way, we sincerely thank > you for all the efforts and contributions. > > -- David Chieu > Actually, I believe the statement made during PSARC is that this case should have its timeout extended by another 24 hours. So, this gives Gary (or anyone else) the option of derailing, or allowing the case to self-approve by timeout. -- Garrett From David.Chieu@sun.com Wed Feb 27 13:21:10 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1RLLAJG001852 for ; Wed, 27 Feb 2008 13:21:10 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1RLL7Db018715; Wed, 27 Feb 2008 13:21:09 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWX00K1P1Z9JJ00@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 14:21:09 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWX00C9A1Z8WT60@brm-avmta-1.central.sun.com>; Wed, 27 Feb 2008 14:21:08 -0700 (MST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1RLL82x017393; Wed, 27 Feb 2008 13:21:08 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWX008011RVZ100@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM); Wed, 27 Feb 2008 13:21:08 -0800 (PST) Received: from [10.1.48.114] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWX00LZK1YZJL50@fe-sfbay-10.sun.com>; Wed, 27 Feb 2008 13:21:00 -0800 (PST) Date: Wed, 27 Feb 2008 13:21:34 -0800 From: David Chieu Subject: Re: Gary please Approve or Derail PSARC 2008/021? In-reply-to: <47C5CD40.6090605@sun.com> Sender: David.Chieu@sun.com To: "Garrett D'Amore" Cc: Gary Winiger , Phi Tran , psarc-ext@sun.com, solaris-battery-team@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com, Randy Fishel Message-id: <47C5D45E.5020002@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802270708.m1R78SNV000448@marduk.eng.sun.com> <47C566E7.9040306@Sun.COM> <47C5C090.6000401@sun.com> <47C5CD40.6090605@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 949 Garrett D'Amore wrote: > David Chieu wrote: >> Gary, >> >> Per PSARC meeting today, the ARC asked a closure of this case in >> which you are the named arbiter. We've learned a lot from your >> comments and because of your pointers we've improved our architecture >> based upon your guidance, especially in the security area. However, >> the case lasted longer than any us of wanted as a FastTrack. So, >> please answer with an approval (I know, with strings attached) or >> derail this case and help us out as a full case sponsor. Either way, >> we sincerely thank you for all the efforts and contributions. >> >> -- David Chieu >> > > Actually, I believe the statement made during PSARC is that this case > should have its timeout extended by another 24 hours. So, this gives > Gary (or anyone else) the option of derailing, or allowing the case to > self-approve by timeout. > > -- Garrett > You're correct, Garrett. -- David Chieu From David.Chieu@sun.com Fri Feb 29 10:56:08 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1TIu8gb023409 for ; Fri, 29 Feb 2008 10:56:08 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1TIu4xB006591; Fri, 29 Feb 2008 10:56:07 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JX000F01KLIRS00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 29 Feb 2008 10:56:06 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX000CKPKLH3O60@nwk-avmta-1.sfbay.Sun.COM>; Fri, 29 Feb 2008 10:56:06 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1TIu5hw013626; Fri, 29 Feb 2008 10:56:05 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX000801K2DWE00@fe-sfbay-09.sun.com> (original mail from David.Chieu@Sun.COM); Fri, 29 Feb 2008 10:56:05 -0800 (PST) Received: from [10.1.48.114] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX00047WKLAQH80@fe-sfbay-09.sun.com>; Fri, 29 Feb 2008 10:56:03 -0800 (PST) Date: Fri, 29 Feb 2008 10:56:33 -0800 From: David Chieu Subject: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 01/28/2008] Sender: David.Chieu@sun.com To: PSARC-ext@sun.com Cc: tamarack-core@sun.com, x86power-iteam@sun.com, solaris-battery-team Message-id: <47C85561.1060201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 230 PSARC 2008/021 HAL Power Management Support has timed out and no one derailing it. So, per last PSARC meeting, the project team believes PSARC/2008/021 case is now self-approved by timeout. We sincerely thank for all involved. From David.Chieu@sun.com Fri Feb 29 11:54:46 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1TJsjmm026613 for ; Fri, 29 Feb 2008 11:54:45 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1TJsTtV006654; Fri, 29 Feb 2008 19:54:43 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JX000211NB6SH00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 29 Feb 2008 11:54:42 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX0002HUNB09H00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 29 Feb 2008 11:54:36 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1TJsavk025943; Fri, 29 Feb 2008 11:54:36 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JX000301N9T2O00@fe-sfbay-10.sun.com> (original mail from David.Chieu@Sun.COM); Fri, 29 Feb 2008 11:54:36 -0800 (PST) Received: from [10.1.48.114] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JX000283NAZRA90@fe-sfbay-10.sun.com>; Fri, 29 Feb 2008 11:54:35 -0800 (PST) Date: Fri, 29 Feb 2008 11:55:10 -0800 From: David Chieu Subject: Re: HAL Power Management Support [PSARC/2008/021 FastTrack timeout 01/28/2008] In-reply-to: <47C85561.1060201@sun.com> Sender: David.Chieu@sun.com Cc: PSARC-ext@sun.com, tamarack-core@sun.com, x86power-iteam@sun.com, solaris-battery-team , Glenn Skinner Message-id: <47C8631E.7000003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47C85561.1060201@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080213) Status: RO Content-Length: 409 David Chieu wrote: > PSARC 2008/021 HAL Power Management Support has timed out and no one > derailing it. So, per last PSARC meeting, the project team believes > PSARC/2008/021 case is now self-approved by timeout. We sincerely > thank for all involved. Glenn Skinner had mentioned this terminology nit to me. I stand corrected - the case was not self-approved, it was simply approved. Sorry about that.