From sacadmin Tue Aug 26 13:30:07 2008 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 m7QKU7T4009318; Tue, 26 Aug 2008 13:30:07 -0700 (PDT) Received: (from dp@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m7QKU7xP009314; Tue, 26 Aug 2008 13:30:07 -0700 (PDT) Date: Tue, 26 Aug 2008 13:30:07 -0700 (PDT) From: Dan Price Message-Id: <200808262030.m7QKU7xP009314@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: coreadm Configuration Refinements [PSARC/2008/551 FastTrack timeout 09/03/2008] Status: RO Content-Length: 568 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: coreadm Configuration Refinements 1.2. Name of Document Author/Supplier: Author: David Powell 1.3 Date of This Document: 26 August, 2008 4. Technical Description See the case directory for more detail 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 dp@eng.sun.com Tue Aug 26 13:35: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 m7QKZJmG009447 for ; Tue, 26 Aug 2008 13:35:19 -0700 (PDT) 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 m7QKZFs5012900; Tue, 26 Aug 2008 14:35:18 -0600 (MDT) 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 <0K680050J6IRPC00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Aug 2008 13:35:15 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6800MWY6IRVED0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 26 Aug 2008 13:35:15 -0700 (PDT) Received: from xanadu (xanadu.SFBay.Sun.COM [129.146.228.194]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7QKZFtN011471; Tue, 26 Aug 2008 13:35:15 -0700 (PDT) Date: Tue, 26 Aug 2008 13:35:29 -0700 From: Dan Price Subject: PSARC 2008/551 coreadm configuration refinements To: PSARC-ext@sun.com Cc: David Powell Message-id: <20080826203528.GB6960@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 9769 I'm happy to sponsor the following case for Dave Powell. This case moves core file configuration from a private configuration file to the SMF repository. The changes are proposed for a minor release. -dp ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ coreadm Configuration Refinements David Powell 8/26/2008 Summary: We propose moving coreadm's configuration from the private configuration file /etc/coreadm.conf to the Service Configuration Facility repository. This will require three user-visible modifications to the coreadm command: 1. Use of the coreadm command to change system settings will require the solaris.smf.manage.coreadm and solaris.smf.value.coreadm authorizations instead of the sys_admin privilege. These authorizations will be provided to coreadm by the "Maintenance and Repair" execution profile. 2. Use of the -u option (loads kernel settings from the configuration file) will no longer be committed, and may be removed in a future release. 3. The existence and function of the /etc/coreadm.conf configuration file will no longer be committed. Additionally, we propose delivering a /var/cores directory so administrators and layered software have a known available location for storing core files. These changes are proposed for delivery into a minor release. Justification: Storing coreadm's configuration in the SCF repository: simplifies access to its configuration, lets coreadm take advantage of future projects that enhance SCF configuration management, and permits finer-grained assignment of coreadm administration responsibilities. Additional information on 'coreadm -u': A web search showed that there is widespread misunderstanding of 'coreadm -u' outside of Sun. 'coreadm -u' is used at boot to take the contents of the coreadm.conf file and apply them to the kernel. Most, if not all, non-Sun references found said either: - It is needed to apply changes to the kernel after changing configuration using other coreadm invocations. This is incorrect: changes made using other coreadm invocations are applied the kernel immediately. coreadm -u is no-op in this case. - It is needed to store changes made to the kernel so that they are applied on next-boot. This is also incorrect: changes made using other coreadm invocations are stored persistently. coreadm -u is also a no-op in this case. For compatibility and to support upgrade, coreadm -u's behavior will continue to read in coreadm.conf, if it exists, and apply the configuration to the kernel. On upgrade coreadm.conf will be moved aside, so the no-op behavior unknowingly assumed in the above cases will also be preserved. Additional information on authorizations and privileges: coreadm documentation currently states that users with the sys_admin privilege are able to use it to change system core file settings. This doesn't completely work today. Users with only that additional privilege are unable to make modifications to the /etc/coreadm.conf configuration file, so coreadm invocations only partially succeed. The new authorizations are sufficient for performing all operations. The aforementioned execution profile correctly encapsulates these authorizations. Documentation changes: --- filesystem.5 Tue Aug 19 16:00:09 2008 +++ filesystem.5.new Tue Aug 19 16:14:21 2008 @@ -788,6 +788,11 @@ Basic Security Module (BSM) audit files. + /var/cores + + Default depository for core files. + + /var/crash Default depository for kernel crash dumps. --- coreadm.1m Tue Aug 19 16:00:06 2008 +++ coreadm.1m.new Tue Aug 19 16:14:11 2008 @@ -15,22 +15,19 @@ coreadm [-p pattern] [-P content] [pid]... - coreadm -u - - DESCRIPTION coreadm specifies the name and location of core files produced by abnormally-terminating processes. See core(4). - Only users who have the sys_admin privilege can execute the first - form of the SYNOPSIS. This form configures system-wide core file - options, including a global core file name pattern and a core - file name pattern for the init(1M) process. All settings are - saved in coreadm's configuration file /etc/coreadm.conf to set at - boot. See init(1M). + Only users and roles that belong to the "Maintenance and Repair" + RBAC profile can execute the first form of the SYNOPSIS. This form + configures system-wide core file options, including a global core + file name pattern and a core file name pattern for the init(1M) + process. All settings are saved persistently and will be applied + at boot. Nonprivileged users can execute the second form of the SYNOPSIS. @@ -39,13 +36,6 @@ file. - Only users who have the sys_admin privilege can execute the third - form of the SYNOPSIS. This form updates all system-wide core file - options, based on the contents of /etc/coreadm.conf. Normally, - this option is used on reboot when starting - svc:/system/coreadm:default. - - A core file name pattern is a normal file system path name with embedded variables, specified with a leading % character. The variables are expanded from values that are effective when a core @@ -220,8 +210,9 @@ -e option for descriptions of possible options. Multiple -e and -d options can be specified on - the command line. Only users with the sys_admin - privilege can use this option. + the command line. Only users and roles belonging + to the "Maintenance and Repair" RBAC profile can + use this option. -e option... Enable the specified core file option. Specify @@ -248,9 +239,10 @@ per-process core pattern. Multiple -e and -d options can be - specified on the command line. - Only users with the sys_admin - privilege can use this option. + specified on the command line. + Only users and roles belonging to + the "Maintenance and Repair" RBAC + profile can use this option. @@ -259,8 +251,8 @@ any of the special % variables that are described in the DESCRIPTION. - Only users with the sys_admin privilege can use - this option. + Only users and roles belonging to the "Maintenance + and Repair" RBAC profile can use this option. -G content Set the global core file content to content. You @@ -267,8 +259,8 @@ must specify content by using the tokens that are described in the DESCRIPTION. - Only users with the sys_admin privilege can use - this option. + Only users and roles belonging to the "Maintenance + and Repair" RBAC profile can use this option. -i pattern Set the default per-process core file name to @@ -280,8 +272,8 @@ (using the -p option) are unaffected. This default persists across reboot. - Only users with the sys_admin or proc_owner - privilege can use this option. + Only users and roles belonging to the "Maintenance + and Repair" RBAC profile can use this option. -I content Set the default per-process core file content to @@ -293,8 +285,8 @@ (using the -P option) are unaffected. This default persists across reboot. - Only users with the sys_admin or proc_owner - privileges can use this option. + Only users and roles belonging to the "Maintenance + and Repair" RBAC profile can use this option. -p pattern Set the per-process core file name pattern to @@ -339,20 +331,8 @@ coreadm). - -u Update system-wide core file options from the - contents of the configuration file - /etc/coreadm.conf. If the configuration file is - missing or contains invalid values, default - values are substituted. Following the update, the - configuration file is resynchronized with the - system core file configuration. - Only users with the sys_admin privilege can use - this option. - - - OPERANDS The following operands are supported: @@ -411,11 +391,13 @@ FILES - /etc/coreadm.conf + /var/cores + Directory provided for global core file storage. + EXIT STATUS The following exit values are returned: @@ -447,7 +429,8 @@ SEE ALSO gcore(1), svcs(1), init(1M), svcadm(1M), exec(2), fork(2), - setuid(2), time(2), syslog(3C), core(4), attributes(5), smf(5) + setuid(2), time(2), syslog(3C), core(4), attributes(5), smf(5), + prof_attr(4), user_attr(4), pfexec(1) ------ ------ ------ ------ ------ ------ ------ ------ ------ ------ -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From Scott.Rotondo@Sun.COM Tue Aug 26 14:07:57 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QL7vZx011869 for ; Tue, 26 Aug 2008 14:07:57 -0700 (PDT) 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 m7QL7vP0027263 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 14:07:57 -0700 (PDT) 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 <0K68009098197100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 14:07:57 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K68006SA817DFC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 14:07:56 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7QL7tvq004648 for ; Tue, 26 Aug 2008 21:07:55 +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 <0K6800B0172Q3O00@mail-amer.sun.com> (original mail from Scott.Rotondo@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 15:07:55 -0600 (MDT) Received: from [129.146.108.62] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800A1M80Y3Y60@mail-amer.sun.com>; Tue, 26 Aug 2008 15:07:47 -0600 (MDT) Date: Tue, 26 Aug 2008 14:07:46 -0700 From: Scott Rotondo Subject: Re: PSARC 2008/551 coreadm configuration refinements In-reply-to: <20080826203528.GB6960@eng.sun.com> Sender: Scott.Rotondo@Sun.COM To: PSARC-ext@Sun.COM Cc: David Powell Message-id: <48B470A2.80606@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080826203528.GB6960@eng.sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 1404 I fully support the changes described here, but I have a couple of comments/questions about minor details. 1. The man page should document the specific authorizations needed, just as it used to document the specific privilege. It's fine to mention that the Maintenance and Repair profile provides these authorizations, but they could be provided by other profiles also. [In other words, the authorization name is the real interface, not the profile name.] > Multiple -e and -d options can be specified on > - the command line. Only users with the sys_admin > - privilege can use this option. > + the command line. Only users and roles belonging > + to the "Maintenance and Repair" RBAC profile can > + use this option. Suggest: Only users and roles with the solaris.smf.manage.coreadm and solaris.smf.value.coreadm authorizations can use this option. 2. The text below may imply more than you intended: > + /var/cores > + > + Default depository for core files. > + > + It appears that this case creates the /var/cores directory but doesn't change the default core file pattern to put core files there. Unless I've overlooked that part of the proposal, the wording used at the end of the man page is probably better: "Directory provided for global core file storage" Scott From David.Powell@sun.com Tue Aug 26 14:35:58 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7QLZwXX012927 for ; Tue, 26 Aug 2008 14:35:58 -0700 (PDT) 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 m7QLZrip005746 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 14:35:58 -0700 (PDT) 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 <0K6800C079BXBU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 14:35:57 -0700 (PDT) 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 <0K68009SH9BXTQ40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 14:35:57 -0700 (PDT) Received: from [129.146.228.208] (schenectady.SFBay.Sun.COM [129.146.228.208]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7QLZu6I053927; Tue, 26 Aug 2008 14:35:57 -0700 (PDT) Date: Tue, 26 Aug 2008 14:33:49 -0700 From: David Powell Subject: Re: PSARC 2008/551 coreadm configuration refinements In-reply-to: <48B470A2.80606@sun.com> To: Scott Rotondo Cc: PSARC-ext@sun.com Message-id: <48B476BD.6060802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080826203528.GB6960@eng.sun.com> <48B470A2.80606@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 2525 Scott Rotondo wrote: > I fully support the changes described here, but I have a couple of > comments/questions about minor details. > > 1. The man page should document the specific authorizations needed, just > as it used to document the specific privilege. It's fine to mention that > the Maintenance and Repair profile provides these authorizations, but > they could be provided by other profiles also. [In other words, the > authorization name is the real interface, not the profile name.] > >> Multiple -e and -d options can be specified on >> - the command line. Only users with the sys_admin >> - privilege can use this option. >> + the command line. Only users and roles belonging >> + to the "Maintenance and Repair" RBAC profile can >> + use this option. > > Suggest: Only users and roles with the solaris.smf.manage.coreadm and > solaris.smf.value.coreadm authorizations can use this option. When researching the case, I was advised to look at the dladm man page. It takes the approach of documenting the necessary profile. I'm not wedded to either approach, though I have to say that the profile has the appeal of being an interface that can be more easily maintained in the face of implementation changes. i.e. if the previously documented mechanism actually worked, I would have been more concerned about changing coreadm from requiring privileges to requiring authorizations. If it had been documented in terms of the profile, there would be no cause for concern regardless of the change. Given this, the precedent set by dladm, and that in the common case coreadm users should just be using the provided profile (i.e. referring first to the profile makes the man page more useful documentation), would it instead be acceptable to document the authorizations in an auxiliary section (e.g. NOTES) leaving the profile as the "primary" documented interface? > 2. The text below may imply more than you intended: > >> + /var/cores >> + >> + Default depository for core files. >> + >> + > > It appears that this case creates the /var/cores directory but doesn't > change the default core file pattern to put core files there. Unless > I've overlooked that part of the proposal, the wording used at the end > of the man page is probably better: "Directory provided for global core > file storage" Good idea. Dave From gww@eng.sun.com Tue Aug 26 15:04: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 m7QM4ZRn013659 for ; Tue, 26 Aug 2008 15:04:36 -0700 (PDT) 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 m7QM4VVp003368 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 26 Aug 2008 23:04:35 +0100 (BST) 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 <0K6800J09ANKQH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 16:04:32 -0600 (MDT) 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 <0K6800CE2ANJHXF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 26 Aug 2008 16:04:31 -0600 (MDT) 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 m7QM4Vmf009005; Tue, 26 Aug 2008 15:04:31 -0700 (PDT) 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 m7QM0nBP017418; Tue, 26 Aug 2008 15:00:49 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m7QM0nTl017417; Tue, 26 Aug 2008 15:00:49 -0700 (PDT) Date: Tue, 26 Aug 2008 15:00:49 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC 2008/551 coreadm configuration refinements To: Scott.Rotondo@sun.com, David.Powell@sun.com Cc: PSARC-ext@sun.com Message-id: <200808262200.m7QM0nTl017417@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1846 > >> Multiple -e and -d options can be specified on > >> - the command line. Only users with the sys_admin > >> - privilege can use this option. > >> + the command line. Only users and roles belonging > >> + to the "Maintenance and Repair" RBAC profile can > >> + use this option. > > > > Suggest: Only users and roles with the solaris.smf.manage.coreadm and > > solaris.smf.value.coreadm authorizations can use this option. > > When researching the case, I was advised to look at the dladm man > page. It takes the approach of documenting the necessary profile. Possibly not architecturally relevant, but clearly a Docs issue that I've tried to put on the plate for years is just how to document Rights Profiles and their relationship to auths and commands. Sigh, not happened yet. I believe I suggested look at dladm / use the Rights Profile as the solution here. The architectural question is where the user interface is. Is it at the authorization level, or the Rights Profile level. If it's at the Rights Profile level then the implementation can be changed without breaking compatibility. If it's at the authorization level, then that must be maintained. For example, if a command in a profile today requires the foo privilege and a later change it requires the foo and bar privileges, if the Rights Profile is the supported interface for that command, adding the bar privilege requirement is a compatible change, while requiring a new privilege may not be a compatible change. I'm not suggesting we duke it out in this Fast-Track, but I am (again) suggesting that the RBAC project team has not completed the task of defining what is to be documented as the User/Admin interface. Gary.. From Scott.Rotondo@sun.com Wed Aug 27 15:15:48 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7RMFmr2028398 for ; Wed, 27 Aug 2008 15:15:48 -0700 (PDT) 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 m7RMFjNq018065 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 27 Aug 2008 15:15:48 -0700 (PDT) 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 <0K6A00A0V5UA4X00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 27 Aug 2008 16:15:46 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6A004YK5U9XJE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 27 Aug 2008 16:15:45 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7RMFjD8002224 for ; Wed, 27 Aug 2008 22:15:45 +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 <0K6A001015B5NO00@mail-amer.sun.com> (original mail from Scott.Rotondo@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 27 Aug 2008 16:15:45 -0600 (MDT) Received: from [129.146.108.62] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6A00BST5TVSRF0@mail-amer.sun.com>; Wed, 27 Aug 2008 16:15:32 -0600 (MDT) Date: Wed, 27 Aug 2008 15:15:31 -0700 From: Scott Rotondo Subject: Re: PSARC 2008/551 coreadm configuration refinements In-reply-to: <48B476BD.6060802@sun.com> Sender: Scott.Rotondo@sun.com To: David Powell Cc: PSARC-ext@sun.com Message-id: <48B5D203.5060803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080826203528.GB6960@eng.sun.com> <48B470A2.80606@sun.com> <48B476BD.6060802@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080422) Status: RO Content-Length: 4123 David Powell wrote: > Scott Rotondo wrote: >> I fully support the changes described here, but I have a couple of >> comments/questions about minor details. >> >> 1. The man page should document the specific authorizations needed, >> just as it used to document the specific privilege. It's fine to >> mention that the Maintenance and Repair profile provides these >> authorizations, but they could be provided by other profiles also. [In >> other words, the authorization name is the real interface, not the >> profile name.] >> >>> Multiple -e and -d options can be specified on >>> - the command line. Only users with the sys_admin >>> - privilege can use this option. >>> + the command line. Only users and roles belonging >>> + to the "Maintenance and Repair" RBAC profile can >>> + use this option. >> >> Suggest: Only users and roles with the solaris.smf.manage.coreadm and >> solaris.smf.value.coreadm authorizations can use this option. > > When researching the case, I was advised to look at the dladm man > page. It takes the approach of documenting the necessary profile. > > I'm not wedded to either approach, though I have to say that the > profile has the appeal of being an interface that can be more easily > maintained in the face of implementation changes. i.e. if the > previously documented mechanism actually worked, I would have been > more concerned about changing coreadm from requiring privileges to > requiring authorizations. If it had been documented in terms of the > profile, there would be no cause for concern regardless of the > change. > > Given this, the precedent set by dladm, and that in the common case > coreadm users should just be using the provided profile (i.e. > referring first to the profile makes the man page more useful > documentation), would it instead be acceptable to document the > authorizations in an auxiliary section (e.g. NOTES) leaving the > profile as the "primary" documented interface? So apparently there is more divided opinion on this issue than I thought. Who would have guessed? ;-) I think that individual privilege and authorization names should be the stable interfaces presented to administrators rather than the names of RBAC profiles that contain them. My reasons for this view include the following: 1. There are other, equally valid, ways for users to acquire authorizations and processes to acquire privileges besides the use of RBAC profiles. Individual privileges and authorizations can be specified in user_attr entries and in SMF service manifests. Many processes also gain privileges by running with uid 0. 2. There is no intent to prevent overlap between RBAC profiles. The same authorization, for example, may be granted by multiple profiles included in Solaris, as well as additional ones defined by the user. In such an environment, there is no obvious rationale for selecting which profile to specify on a man page like this one. 3. Authorizations and privileges exist in order to allow an administrator to implement the principle of least privilege, i.e. to grant a minimal set of rights needed to accomplish a particular purpose. In order to construct such a set, an administrator needs to know the function of each privilege or authorization and needs to know which ones are required by each administrative program. 4. Privilege names, at least, cannot be considered as implementation details that are subject to change within an RBAC profile because the specific privileges are documented on the man pages of system calls that require them. Although this argument does not apply to authorizations, I think they should be treated similarly for the reasons described above. Having said all that, this is a general architectural issue that should not hold up the current fast-track. PSARC members: What is the best mechanism to reach consensus on this issue and ensure that current and future documentation complies with that consensus? Scott From David.Powell@sun.com Thu Aug 28 17:26:17 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7T0QH5P014898 for ; Thu, 28 Aug 2008 17:26:17 -0700 (PDT) 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 m7T0QHIT009468 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 28 Aug 2008 17:26:17 -0700 (PDT) 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 <0K6C008036JSPW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 28 Aug 2008 18:26:16 -0600 (MDT) 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 <0K6C002Q86JRLM60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 28 Aug 2008 18:26:16 -0600 (MDT) Received: from [129.146.228.208] (schenectady.SFBay.Sun.COM [129.146.228.208]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7T0QFMv026251; Thu, 28 Aug 2008 17:26:15 -0700 (PDT) Date: Thu, 28 Aug 2008 17:24:06 -0700 From: David Powell Subject: Re: PSARC 2008/551 coreadm configuration refinements In-reply-to: <48B5D203.5060803@sun.com> To: Scott Rotondo Cc: PSARC-ext@sun.com Message-id: <48B741A6.8020402@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080826203528.GB6960@eng.sun.com> <48B470A2.80606@sun.com> <48B476BD.6060802@sun.com> <48B5D203.5060803@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 2890 Scott Rotondo wrote: > David Powell wrote: >> When researching the case, I was advised to look at the dladm man >> page. It takes the approach of documenting the necessary profile. >> >> I'm not wedded to either approach, though I have to say that the >> profile has the appeal of being an interface that can be more easily >> maintained in the face of implementation changes. i.e. if the >> previously documented mechanism actually worked, I would have been >> more concerned about changing coreadm from requiring privileges to >> requiring authorizations. If it had been documented in terms of the >> profile, there would be no cause for concern regardless of the >> change. >> >> Given this, the precedent set by dladm, and that in the common case >> coreadm users should just be using the provided profile (i.e. >> referring first to the profile makes the man page more useful >> documentation), would it instead be acceptable to document the >> authorizations in an auxiliary section (e.g. NOTES) leaving the >> profile as the "primary" documented interface? > > So apparently there is more divided opinion on this issue than I > thought. Who would have guessed? ;-) > > I think that individual privilege and authorization names should be the > stable interfaces presented to administrators rather than the names of > RBAC profiles that contain them. My reasons for this view include the > following: [Reasons I mostly agree with elided] > 4. Privilege names, at least, cannot be considered as implementation > details that are subject to change within an RBAC profile because the > specific privileges are documented on the man pages of system calls that > require them. Although this argument does not apply to authorizations, I > think they should be treated similarly for the reasons described above. But which system calls a command uses to accomplish something are themselves implementation details. It's then our choice whether we expose the privileges those system calls require as privileges the command requires, or we expose an abstraction that hides the underlying authorization mechanism. In other words, though our choice of interface might restrict the system calls we are allowed to use, the choice of system calls doesn't necessarily impact how the command is presented to the user. > Having said all that, this is a general architectural issue that > should not hold up the current fast-track. PSARC members: What is the > best mechanism to reach consensus on this issue and ensure that > current and future documentation complies with that consensus? I don't have a problem with documenting the Authorizations; the reasons for doing so do make a lot of sense. I look forward to your guidance regarding how the different authorization mechanisms should documented. Dave From Scott.Rotondo@sun.com Fri Aug 29 09:57: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 m7TGvFVu009234 for ; Fri, 29 Aug 2008 09:57:16 -0700 (PDT) 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 m7TGvEKW036536 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 29 Aug 2008 10:57:15 -0600 (MDT) 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 <0K6D00105GFFSY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Aug 2008 09:57:15 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6D00HXPGFDS3B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Aug 2008 09:57:14 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7TGvDT5023522 for ; Fri, 29 Aug 2008 16:57:13 +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 <0K6D00I01CFL4N00@mail-amer.sun.com> (original mail from Scott.Rotondo@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Aug 2008 10:57:13 -0600 (MDT) Received: from viaggio.local ([69.226.223.222]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6D00IJMGF3JXB0@mail-amer.sun.com>; Fri, 29 Aug 2008 10:57:03 -0600 (MDT) Date: Fri, 29 Aug 2008 09:57:34 -0700 From: Scott Rotondo Subject: Re: PSARC 2008/551 coreadm configuration refinements In-reply-to: <48B741A6.8020402@sun.com> Sender: Scott.Rotondo@sun.com To: David Powell Cc: PSARC-ext@sun.com Message-id: <48B82A7E.8060106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080826203528.GB6960@eng.sun.com> <48B470A2.80606@sun.com> <48B476BD.6060802@sun.com> <48B5D203.5060803@sun.com> <48B741A6.8020402@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 2064 David Powell wrote: > Scott Rotondo wrote: > >> 4. Privilege names, at least, cannot be considered as implementation >> details that are subject to change within an RBAC profile because the >> specific privileges are documented on the man pages of system calls >> that require them. Although this argument does not apply to >> authorizations, I think they should be treated similarly for the >> reasons described above. > > But which system calls a command uses to accomplish something are > themselves implementation details. It's then our choice whether we > expose the privileges those system calls require as privileges the > command requires, or we expose an abstraction that hides the > underlying authorization mechanism. > > In other words, though our choice of interface might restrict the > system calls we are allowed to use, the choice of system calls > doesn't necessarily impact how the command is presented to the user. That's a valid point. However, for commands that use privileged system calls, I think we will need to document their required privileges if we want others to be able to create new entities (such as RBAC profiles and SMF actions) that use the commands. Incidentally, did I correctly infer that the future coreadm will require *only* authorizations (because it will store all state in SMF properties rather than files that require privilege to write)? > >> Having said all that, this is a general architectural issue that >> should not hold up the current fast-track. PSARC members: What is the >> best mechanism to reach consensus on this issue and ensure that >> current and future documentation complies with that consensus? > > I don't have a problem with documenting the Authorizations; the > reasons for doing so do make a lot of sense. I look forward to your > guidance regarding how the different authorization mechanisms should > documented. > PSARC members: How can I best propose, and get approval for, such guidance? Should this be a "best practice" submission? Scott From Nicolas.Williams@sun.com Fri Aug 29 10:27:58 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7THRwSA009901 for ; Fri, 29 Aug 2008 10:27:58 -0700 (PDT) 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 m7THRqeE025957; Fri, 29 Aug 2008 10:27:57 -0700 (PDT) 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 <0K6D00F0PHUK5800@brm-avmta-1.central.sun.com>; Fri, 29 Aug 2008 11:27:56 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6D00D24HUJ5950@brm-avmta-1.central.sun.com>; Fri, 29 Aug 2008 11:27:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m7THRt5W029574; Fri, 29 Aug 2008 12:27:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m7THRtcG029573; Fri, 29 Aug 2008 12:27:55 -0500 (CDT) Date: Fri, 29 Aug 2008 12:27:55 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/551 coreadm configuration refinements In-reply-to: <48B5D203.5060803@sun.com> To: Scott Rotondo Cc: David Powell , PSARC-ext@sun.com Mail-followup-to: Scott Rotondo , David Powell , PSARC-ext@sun.com Message-id: <20080829172754.GM20924@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080826203528.GB6960@eng.sun.com> <48B470A2.80606@sun.com> <48B476BD.6060802@sun.com> <48B5D203.5060803@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2330 On Wed, Aug 27, 2008 at 03:15:31PM -0700, Scott Rotondo wrote: > So apparently there is more divided opinion on this issue than I > thought. Who would have guessed? ;-) > > I think that individual privilege and authorization names should be the > stable interfaces presented to administrators rather than the names of > RBAC profiles that contain them. My reasons for this view include the > following: > > [...] > > 2. There is no intent to prevent overlap between RBAC profiles. The same > authorization, for example, may be granted by multiple profiles included > in Solaris, as well as additional ones defined by the user. In such an > environment, there is no obvious rationale for selecting which profile > to specify on a man page like this one. > > [...] IMO profile names and semantics are more likely to be stable than authorization names and their semantics. That is mostly because authorizations are very specific and therefore tend to expose some implementation details (e.g., the 'smf' part of most authoritzations used by SMF services), whereas profiles are typically, and by necessity broader in scope than authorizations. That customers can create new profiles that overlap with Sun-provided profiles is actually a good thing: it allows customers to deal with backwards incompatible changes to authorizations (e.g., removals of authorizations) by updating just the affected customer-maintained profiles, as opposed to the affected user_attr(4) entries. The former is easier to do than the latter. The change that's really interesting in this case is that coreadm will no longer require use of pfexec (or profile shell, or root shell) to execute it with privilege, but using pfexec as usual will not break. The inverse would not have been a backward compatible change. IMO we should encourage developers to design suitable profiles and make their interface stability match that of the most stable project component related to that profile, and we should allow authorizations to be less stable. E.g., "profiles should be Committed and authorizations may be Uncommitted." And we should explicitly document "requires privilege"->"requires authorization" changes as backward compatible while the reverse is not [until a project comes along that makes explicit use of pfexec unnecessary]. Nico -- From David.Powell@Sun.COM Fri Aug 29 11:33:25 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 m7TIXOUH012201 for ; Fri, 29 Aug 2008 11:33:25 -0700 (PDT) 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 m7TIXIwP007173 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 30 Aug 2008 02:33:24 +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 <0K6D00501KVNU300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Aug 2008 11:33:23 -0700 (PDT) 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 <0K6D005EWKVM3O10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 29 Aug 2008 11:33:22 -0700 (PDT) Received: from [129.146.228.208] (schenectady.SFBay.Sun.COM [129.146.228.208]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7TIXMIp044863; Fri, 29 Aug 2008 11:33:22 -0700 (PDT) Date: Fri, 29 Aug 2008 11:31:12 -0700 From: David Powell Subject: Re: PSARC 2008/551 coreadm configuration refinements In-reply-to: <48B82A7E.8060106@sun.com> To: Scott Rotondo Cc: PSARC-ext@Sun.COM Message-id: <48B84070.9070407@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20080826203528.GB6960@eng.sun.com> <48B470A2.80606@sun.com> <48B476BD.6060802@sun.com> <48B5D203.5060803@sun.com> <48B741A6.8020402@sun.com> <48B82A7E.8060106@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080602) Status: RO Content-Length: 475 Scott Rotondo wrote: > Incidentally, did I correctly infer that the future coreadm will require > *only* authorizations (because it will store all state in SMF properties > rather than files that require privilege to write)? Normally, yes. When coreadm is run with the now undocumented -u option, though, it will still require privileges to function. There is also no change to the mode of operation in which coreadm is applied to another process. Dave From MAILER-DAEMON Mon Sep 22 17:39: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 m8N0dJGr011081 for ; Mon, 22 Sep 2008 17:39:19 -0700 (PDT) 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 m8N0dHNl055032; Mon, 22 Sep 2008 18:39:18 -0600 (MDT) 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 <0K7M00D05HTHHT00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Sep 2008 17:39:17 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7M00ATSHTHP530@nwk-avmta-1.sfbay.Sun.COM>; Mon, 22 Sep 2008 17:39:17 -0700 (PDT) Received: from xanadu (xanadu.SFBay.Sun.COM [129.146.228.194]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8N0dHF1498037; Mon, 22 Sep 2008 17:39:17 -0700 (PDT) Date: Mon, 22 Sep 2008 17:39:20 -0700 From: Dan Price Subject: Re: PSARC 2008/551 coreadm configuration refinements In-reply-to: <20080826203528.GB6960@eng.sun.com> To: PSARC-ext@sun.com Cc: David Powell Message-id: <20080923003916.GA26655@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080826203528.GB6960@eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 445 On Tue 26 Aug 2008 at 01:35PM, Dan Price wrote: > > I'm happy to sponsor the following case for Dave Powell. This case > moves core file configuration from a private configuration file to > the SMF repository. The changes are proposed for a minor release. This case was approved at the 9/10/2008 PSARC meeting. I am marking it closed-approved. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp