From lianep@kodiak.sfbay.sun.com Thu Feb 8 17:14:54 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l191Erie016217 for ; Thu, 8 Feb 2007 17:14:53 -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 l191EMs1009556 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Fri, 9 Feb 2007 09:14: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 <0JD6008018SQX700@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 08 Feb 2007 17:14:50 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JD600G7A8SPH1F0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 08 Feb 2007 17:14:50 -0800 (PST) Received: from kodiak.sfbay.sun.com (kodiak.SFBay.Sun.COM [192.29.75.57]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l191EnuY025639 for ; Thu, 08 Feb 2007 17:14:49 -0800 (PST) Received: from kodiak (localhost [127.0.0.1]) by kodiak.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l191En50846846; Thu, 08 Feb 2007 17:14:49 -0800 (PST) Date: Thu, 08 Feb 2007 17:14:49 -0800 From: Liane Praza Subject: 2007/084 Clarification to SMF Policy Sender: lianep@kodiak.sfbay.sun.com To: psarc-ext@sun.com Cc: smf-discuss@opensolaris.org Message-id: <200702090114.l191En50846846@kodiak.sfbay.sun.com> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2592 I am sponsoring this fasttrack for Tony Nguyen. We believe it qualifies as closed approved automatic, as it makes minor clarifications only to an existing policy. Note that I have set this to be an externally visible case, with mail to psarc-ext@sun.com. For those of you on smf-discuss@opensolaris.org, this is a primarily informative mail. If you have specific comments about the changes being made, feel free to raise them in this thread. If you have comments or questions not specifically related to the change proposed in this case, please remove the psarc-ext alias from the cc list, and change the Subject line before responding. liane --- Clarification to SMF Policy Tony Nguyen 08 February 2007 1. Summary This cases proposes to make some simple clarifications to the SMF Policy: http://opensolaris.org/os/community/arc/policies/SMF-policy/ These modifications simply clarify existing policy, and are made based on feedback from consumers of the policy. As no interface nor architectural changes are made, we are filing this case as a self-reviewed Closed Approved Automatic fasttrack. 2. Policy changes --- SMF.bp Thu Feb 8 11:03:30 2007 +++ SMF-new.bp Thu Feb 8 11:08:57 2007 @@ -81,7 +81,8 @@

  • Criteria to determine when a project must deliver SMF services
  • Migration of "legacy" (existing) services to SMF -
  • Requirements for delivery of SMF services +
  • Requirements for delivery of SMF services (for any + restarter, including svc.startd and inetd)
  • Requirements for delivery of new system and system service configuration
@@ -129,7 +130,9 @@ # within this document? How can a project determine # whether this policy applies to them? Scope = - This policy applies to you if you create, modify or use + This policy applies to you if you create or modify SMF + services (for any restarter, including svc.startd and inetd). + This policy also applies to you if you create, modify or use files in any of these locations:
  • /etc/init.d and rc?.d scripts @@ -328,8 +331,8 @@ is the appropriate repository for their data.

    -
    Appendix C: Guidance for services that must be started early in - the boot sequence
    +
    Appendix C: Guidance for service instances delivered as + "enabled"

    Under most circumstances, service manifests should specify their service instances as "disabled". This decouples the -- Liane Praza, Solaris Kernel Development liane.praza@sun.com - http://blogs.sun.com/lianep From pschow@wakulla.Central.Sun.COM Fri Feb 9 07:59:39 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19FxcMs000058 for ; Fri, 9 Feb 2007 07:59:38 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l19Fxa6j027815 for <@sunmail1brm.central.sun.com:psarc-ext@sun.com>; Fri, 9 Feb 2007 15:59:37 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 <0JD700I05DRCE600@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 09 Feb 2007 08:59:36 -0700 (MST) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JD700IJIDRBR7B0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 09 Feb 2007 08:59:35 -0700 (MST) Received: from wakulla.Central.Sun.COM (wakulla.Central.Sun.COM [129.147.49.230]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l19FxYWc017180 for ; Fri, 09 Feb 2007 08:59:35 -0700 (MST) Received: from wakulla.Central.Sun.COM (localhost [127.0.0.1]) by wakulla.Central.Sun.COM (8.13.7+Sun/8.13.7) with ESMTP id l19FxURp003535; Fri, 09 Feb 2007 08:59:30 -0700 (MST) Received: (from pschow@localhost) by wakulla.Central.Sun.COM (8.13.7+Sun/8.13.7/Submit) id l19FxUHN003534; Fri, 09 Feb 2007 08:59:30 -0700 (MST) Date: Fri, 09 Feb 2007 08:59:30 -0700 From: Peter Schow Subject: Re: 2007/084 Clarification to SMF Policy In-reply-to: <200702090114.l191En50846846@kodiak.sfbay.sun.com> To: Liane Praza Cc: psarc-ext@sun.com, smf-discuss@opensolaris.org Message-id: <20070209155929.GA3500@wakulla.Central.Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200702090114.l191En50846846@kodiak.sfbay.sun.com> User-Agent: Mutt/1.5.12-2006-07-14 Status: RO Content-Length: 528 Hi Liane, On Thu, Feb 08, 2007 at 05:14:49PM -0800, Liane Praza wrote: > - This policy applies to you if you create, modify or use > + This policy applies to you if you create or modify SMF > + services (for any restarter, including svc.startd and inetd). How does this affect the existing 26 or so inetd SMF manifests which could be taken out of compliance by this clarification, mainly around the area of specifiying authorizations? This may be a good opportunity for a consistent RBAC review across these services. From lianep@kodiak.sfbay.sun.com Fri Feb 9 08:07:55 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19G7sLj000103 for ; Fri, 9 Feb 2007 08:07:54 -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 l19G7rK8018416 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 9 Feb 2007 08:07:54 -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 <0JD700K1RE559H00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 09 Feb 2007 08:07:53 -0800 (PST) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JD7008DFE534ZE0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 09 Feb 2007 08:07:51 -0800 (PST) Received: from kodiak.sfbay.sun.com (kodiak.SFBay.Sun.COM [192.29.75.57]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l19G7pVI022088; Fri, 09 Feb 2007 08:07:51 -0800 (PST) Received: from kodiak (localhost [127.0.0.1]) by kodiak.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l19G7pVC872387; Fri, 09 Feb 2007 08:07:51 -0800 (PST) Date: Fri, 09 Feb 2007 08:07:51 -0800 From: lianep@eng.sun.com Subject: Re: 2007/084 Clarification to SMF Policy In-reply-to: <20070209155929.GA3500@wakulla.Central.Sun.COM> Sender: lianep@kodiak.sfbay.sun.com To: Peter Schow Cc: Liane Praza , psarc-ext@sun.com, smf-discuss@opensolaris.org Message-id: <200702091607.l19G7pVC872387@kodiak.sfbay.sun.com> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1344 Peter Schow writes: > Hi Liane, > > On Thu, Feb 08, 2007 at 05:14:49PM -0800, Liane Praza wrote: > > - This policy applies to you if you create, modify or use > > + This policy applies to you if you create or modify SMF > > + services (for any restarter, including svc.startd and inetd). > > How does this affect the existing 26 or so inetd SMF manifests which could > be taken out of compliance by this clarification, mainly around the area > of specifiying authorizations? As the policy was not completed before ARC review of services began, there are many services which do not comply with the policy. (For all restarters. The clarification does not introduce new requirements, only clarified a confusion some, but not all, saw when reading the policy.) > This may be a good opportunity for a consistent RBAC review across these > services. I believe a set of bugs/rfes would be the appropriate way to handle this. We couldn't, and still can't make the policy retroactive from an ARC point of view. :) Services which re-visit ARC will have the policy enforced at that time, so there is also incremental improvement. But, again, I agree that we should file bugs/rfes around Solaris services not in compliance today. liane -- Liane Praza, Solaris Kernel Development liane.praza@sun.com - http://blogs.sun.com/lianep From gww@eng.sun.com Fri Feb 9 08:43:59 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l19GhxSa000293 for ; Fri, 9 Feb 2007 08:43:59 -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 l19Ghwqk027182 for <@sunmail1brm.central.sun.com:psarc-ext@sun.com>; Fri, 9 Feb 2007 08:43:58 -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 <0JD700M07FT9LX00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 09 Feb 2007 09:43:57 -0700 (MST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JD700IZLFT7R4E0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 09 Feb 2007 09:43:55 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l19Ghsto019298; Fri, 09 Feb 2007 08:43:54 -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 l19Gidje006600; Fri, 09 Feb 2007 08:44:39 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l19Gidp8006599; Fri, 09 Feb 2007 08:44:39 -0800 (PST) Date: Fri, 09 Feb 2007 08:44:39 -0800 (PST) From: Gary Winiger Subject: Re: 2007/084 Clarification to SMF Policy To: Peter.Schow@sun.com, lianep@eng.sun.com Cc: psarc-ext@sun.com, smf-discuss@opensolaris.org Message-id: <200702091644.l19Gidp8006599@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 413 > I believe a set of bugs/rfes would be the appropriate way to handle this. > We couldn't, and still can't make the policy retroactive from an ARC > point of view. :) > > Services which re-visit ARC will have the policy enforced at that time, > so there is also incremental improvement. But, again, I agree that we > should file bugs/rfes around Solaris services not in compliance today. Exactly. Gary.. From Liane.Praza@eng.sun.com Mon Feb 12 10:37:38 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l1CIbbo9022442 for ; Mon, 12 Feb 2007 10:37:37 -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 l1CIbZM1025775 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Tue, 13 Feb 2007 02:37:36 +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 <0JDD00L0152L3700@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 12 Feb 2007 10:37:33 -0800 (PST) Received: from jurassic.eng.sun.com ([129.146.108.38]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JDD007HL52G92E0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 12 Feb 2007 10:37:28 -0800 (PST) Received: from jurassic (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l1CIb4S6806257; Mon, 12 Feb 2007 10:37:04 -0800 (PST) Date: Mon, 12 Feb 2007 10:37:04 -0800 From: lianep@eng.sun.com Subject: Re: 2007/084 Clarification to SMF Policy In-reply-to: <20070209155929.GA3500@wakulla.Central.Sun.COM> Sender: Liane.Praza@eng.sun.com To: psarc-ext@sun.com, smf-discuss@opensolaris.org Message-id: <200702121837.l1CIb4S6806257@jurassic.eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1463 (I'm re-sending this, as my previous mail bounced back to me. Apologies for any dups and the out-of-order response.) Peter Schow writes: > Hi Liane, > > On Thu, Feb 08, 2007 at 05:14:49PM -0800, Liane Praza wrote: > > - This policy applies to you if you create, modify or use > > + This policy applies to you if you create or modify SMF > > + services (for any restarter, including svc.startd and inetd). > > How does this affect the existing 26 or so inetd SMF manifests which could > be taken out of compliance by this clarification, mainly around the area > of specifiying authorizations? As the policy was not completed before ARC review of services began, there are many services which do not comply with the policy. (For all restarters. The clarification does not introduce new requirements, only clarified a confusion some, but not all, saw when reading the policy.) > This may be a good opportunity for a consistent RBAC review across these > services. I believe a set of bugs/rfes would be the appropriate way to handle this. We couldn't, and still can't make the policy retroactive from an ARC point of view. :) Services which re-visit ARC will have the policy enforced at that time, so there is also incremental improvement. But, again, I agree that we should file bugs/rfes around Solaris services not in compliance today. liane -- Liane Praza, Solaris Kernel Development liane.praza@sun.com - http://blogs.sun.com/lianep