From sacadmin Mon Jul 16 15:14:55 2007 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 l6GMEsqq027936; Mon, 16 Jul 2007 15:14:54 -0700 (PDT) Received: (from markcarl@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l6GMEsap027932; Mon, 16 Jul 2007 15:14:54 -0700 (PDT) Date: Mon, 16 Jul 2007 15:14:54 -0700 (PDT) From: Mark Carlson Message-Id: <200707162214.l6GMEsap027932@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: Tim.Szeto@Sun.COM Subject: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/23/2007] Status: RO Content-Length: 558 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: SCF changes for iSCSI Target 1.2. Name of Document Author/Supplier: Author: Tim Szeto 1.3 Date of This Document: 16 July, 2007 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 sacadmin Tue Jul 24 08:13:45 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l6OFDiSU026690 for ; Tue, 24 Jul 2007 08:13:45 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6OFBa5R029863 for ; Tue, 24 Jul 2007 08:11:36 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6OFBaI2021321 for ; Tue, 24 Jul 2007 15:11:36 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLO00J01VGZEN00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for PSARC-record@sac.sfbay.sun.com; Tue, 24 Jul 2007 09:11:36 -0600 (MDT) Received: from MACsMAC.local ([129.150.36.223]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLO003R1VJBLDJ6@mail-amer.sun.com> for PSARC-record@sac.sfbay.sun.com; Tue, 24 Jul 2007 09:11:36 -0600 (MDT) Date: Tue, 24 Jul 2007 09:11:34 -0600 From: "Mark A. Carlson" Subject: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/23/2007] In-reply-to: <200707162214.l6GMEsap027932@sac.sfbay.sun.com> Sender: Mark.Carlson@Sun.COM To: PSARC-record@sac.sfbay.sun.com Cc: Tim.Szeto@Sun.COM Message-id: <46A616A6.7020505@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200707162214.l6GMEsap027932@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) Status: RO Content-Length: 103 I'm marking this case as closed approved, the timer expired without any issues being raised. -- mark From Mark.Carlson@sun.com Tue Jul 24 15:12:48 2007 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 l6OMCmFm017826 for ; Tue, 24 Jul 2007 15:12:48 -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 l6OMAf5w007185 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 24 Jul 2007 15:10:42 -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 <0JLP0080BEXMTN00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Jul 2007 16:10:34 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLP005UBEXM9890@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Jul 2007 16:10:34 -0600 (MDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6OMAYME003778 for ; Tue, 24 Jul 2007 22:10:34 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLP00901EKH0Z00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Jul 2007 16:10:33 -0600 (MDT) Received: from MACsMAC.local ([129.150.33.221]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLP00334EXLLEX3@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 24 Jul 2007 16:10:33 -0600 (MDT) Date: Tue, 24 Jul 2007 16:10:32 -0600 From: "Mark A. Carlson" Subject: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] Sender: Mark.Carlson@sun.com To: psarc-ext@sun.com Cc: Tim Szeto , Kenneth Davis Message-id: <46A678D8.8060603@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.5 (Macintosh/20070716) Status: RO Content-Length: 4202 I am sponsoring this case for the iSCSI Target team. Timeout has been extended since not everyone saw this this first time. -- mark Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: SCF changes for iSCSI Target 1.2. Name of Document Author/Supplier: Author: Tim Szeto 1.3 Date of This Document: 16 July, 2007 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 SCF design for iSCSI target =========================== High Level: -All configuration files (target_config.xml, config.xml, param.N) are moved to SCF. -Keeping the current incore XML database -the incore database is created from the SCF (need functions to convert SCF->incore) -the incore database will change as follow: -the target_config.xml, config.xml and param.N will merged into 1 database -Need to convert existing configuration to SCF if old configuration files (config.xml, target_config.xml) existed, after converting to SCF, the old configurations are deleted. This would mean keeping some of the existing codes that read in the configuration files and build the incore database, and then use the tgt_dump2scf() to build the SCF. -All the pgroups/properties are create dynamically, the only exception is the iscsitgt pgroup, the properties in this pgroup can be populated with the default value on install. -The CLI still uses the door interface to the daemon, the mgmt interfaces are used to create incore database and then use the mgmt_scf interfaces to create/modify/delete the SCF database. -At startup a mgmt_scf function will open the SCF database and read in the iscsitgt pgroup, and the target pgroups, the SCF data are converted to incore database. -The incore database will have a new property for the target, it will contains param propertes for each LUN. Example of an incore target configuration: t1 0 1 iqn.1986-03.com.sun:02:... <0> 0x10000 . . 039384947504 <1> 0x10000 . . 039377777504 API === -pgroup -create -modify -delete -find -property per pgroup -create -modify -delete -find -Find pgroup (initiator_name, tpgt_num, param_targetname_lun) -Get properties -convert to incore database Startup ------- -Find iscsitgt pgroup (default) -iterate for properties in pgroup -convert to local database -Iterate target_name pgroup -iterate target property -Find initiator_name pgroup -iterate initiator property (iscsi_name, chap_name, chap_secret) -Find tpgt_num group -iterate tpgt property (ip_address) -convert to local database Create pgroup/property ---------------------- -create in core database -create new pgroup (target, initiator, tgpt, param) -create target -create target_name pgroup -create local_name prop -create iscsi_name prop -create .... prop -commit -create initiator -create initiator_name pgroup -create local_name prop -commit -create tpgt -create ip_addr prop -commit Modify property --------------- -modify in core database -find pgroup -find property -modify property -commit Delete pgroup/property ---------------------- -delete pgroup name -find pgroup name -delete properties and then pgroup -delete property on a given pgroup -find pgroup -find prperty -delete property -commit Find pgroup/property -------------------- -find pgroup name -find property given pgroup handle Issue ====== The property CHAP SECRETS is converted to SCF after PSARC 2007/177 is putback. From sommerfeld@sun.com Tue Jul 24 18:04:49 2007 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 l6P14mhm026914 for ; Tue, 24 Jul 2007 18:04:48 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6P12aUX025874; Wed, 25 Jul 2007 02:02:40 +0100 (BST) 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 <0JLP00C01MWGP900@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Jul 2007 18:02:40 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLP000NOMWGAU50@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Jul 2007 18:02:40 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6P12cLd002148; Tue, 24 Jul 2007 21:02:38 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6P12cYr022344; Tue, 24 Jul 2007 21:02:38 -0400 (EDT) Date: Tue, 24 Jul 2007 21:02:37 -0400 From: Bill Sommerfeld Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <46A678D8.8060603@sun.com> To: "Mark A. Carlson" Cc: psarc-ext@sun.com, Tim Szeto , Kenneth Davis Message-id: <1185325357.20267.126.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46A678D8.8060603@sun.com> Status: RO Content-Length: 953 On Tue, 2007-07-24 at 16:10 -0600, Mark A. Carlson wrote: > Issue > ====== > The property CHAP SECRETS is converted to SCF after PSARC 2007/177 > is putback. since no details are provided I'm assuming this means there will be another case which specifies this. I can't find a reference in the case materials to the original iSCSI target case, but I think we screwed up when we approved the original spec which stored the chap secret in the common config file, as this clashes with the spirit of the "Storing Reusable Passwords on a Filesystem" Best Practice; see: http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp this recommends the use of additional protections for sensitive values stored in the filesystem; because 2007/177 merely provides an access control mechanism and not any additional mechanisms (such as encryption). there are unfortunately no really good solutions here; see the current draft 2007/177 opinion for specifics. From Darren.Moffat@sun.com Wed Jul 25 02:18:35 2007 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 l6P9IZLq003694 for ; Wed, 25 Jul 2007 02:18:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6P9GR2k011187 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 25 Jul 2007 02:16:28 -0700 (PDT) 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 <0JLQ00A0N9RFI600@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Jul 2007 02:16:27 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLQ001J59RD7760@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Jul 2007 02:16:25 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6P9GOGv013399 for ; Wed, 25 Jul 2007 09:16:24 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLQ00701947PA00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Jul 2007 10:16:24 +0100 (BST) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLQ00D5T9RBMO30@d1-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 25 Jul 2007 10:16:23 +0100 (BST) Date: Wed, 25 Jul 2007 10:16:23 +0100 From: Darren J Moffat Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <46A678D8.8060603@sun.com> Sender: Darren.Moffat@sun.com To: "Mark A. Carlson" Cc: PSARC-ext@sun.com, Tim Szeto , Kenneth Davis Message-id: <46A714E7.3010905@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: <46A678D8.8060603@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070605) Status: RO Content-Length: 643 Mark A. Carlson wrote: > The property CHAP SECRETS is converted to SCF after PSARC 2007/177 > is putback. How are the chap secrets currently protected ? In the 2007/177 opinion document [1], section 4.5, it states that care needs to be taken when using the facility to store secrets. Does conversion weaken the existing security ? Does it matter ? What is the RBAC authorisation that will be used with the 2007/177 facility to protect the properties used to store the chap secrets ? What RBAC profile is that authorisation in by default ? [1] http://opensolaris.org/os/community/arc/caselog/2007/177/opinion-txt/ -- Darren J Moffat From Tim.Szeto@sun.com Wed Jul 25 08:58:02 2007 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 l6PFw1ao010629 for ; Wed, 25 Jul 2007 08:58:01 -0700 (PDT) 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 l6PFtWnI018062 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jul 2007 23:55:53 +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 <0JLQ0030NS92JX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jul 2007 09:55:50 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLQ00FL9S908UD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jul 2007 09:55:48 -0600 (MDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6PFtm7X024835 for ; Wed, 25 Jul 2007 15:55:48 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLQ00B01S0FLT00@mail-amer.sun.com> (original mail from Tim.Szeto@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jul 2007 09:55:48 -0600 (MDT) Received: from [172.20.58.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLQ00I8MS90C9M3@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jul 2007 09:55:48 -0600 (MDT) Date: Wed, 25 Jul 2007 09:54:51 -0600 From: tim szeto Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <46A714E7.3010905@Sun.COM> Sender: Tim.Szeto@sun.com To: Darren J Moffat Cc: "Mark A. Carlson" , PSARC-ext@sun.com, Kenneth Davis , ChrisL Message-id: <46A7724B.5010804@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: <46A678D8.8060603@sun.com> <46A714E7.3010905@Sun.COM> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 992 Darren, Darren J Moffat wrote: > Mark A. Carlson wrote: > >> The property CHAP SECRETS is converted to SCF after PSARC 2007/177 >> is putback. > > How are the chap secrets currently protected ? Currently it is stored in a file readonly by root. > > In the 2007/177 opinion document [1], section 4.5, it states that care > needs to be taken when using the facility to store secrets. Does > conversion weaken the existing security ? No, it does not weaken the existing security. > Does it matter ? It does matter when a user chose to use CHAP SECRET for their system. > > What is the RBAC authorisation that will be used with the 2007/177 > facility to protect the properties used to store the chap secrets ? The iSCSI daemon uses user credential to verify user accessibility to the iSCSI configuration database. > What RBAC profile is that authorisation in by default ? The default is PRIV_SYS_CONFIG. -tim > > [1] http://opensolaris.org/os/community/arc/caselog/2007/177/opinion-txt/ From gww@eng.sun.com Wed Jul 25 12:51:28 2007 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 l6PJpRb5018906 for ; Wed, 25 Jul 2007 12:51:27 -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 l6PJnG9o023767 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 25 Jul 2007 13:49:19 -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 <0JLR00C173270600@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jul 2007 12:49:19 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR00BTH322EL10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 25 Jul 2007 12:49:14 -0700 (PDT) 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 l6PJnBX9016092; Wed, 25 Jul 2007 12:49:11 -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 l6PJqo93007577; Wed, 25 Jul 2007 12:52:50 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l6PJqops007576; Wed, 25 Jul 2007 12:52:50 -0700 (PDT) Date: Wed, 25 Jul 2007 12:52:50 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] To: Darren.Moffat@sun.com, Tim.Szeto@sun.com Cc: Chris.Liu@sun.com, Kenneth.Davis@sun.com, PSARC-ext@sun.com, Mark.Carlson@sun.com Message-id: <200707251952.l6PJqops007576@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1578 > >> The property CHAP SECRETS is converted to SCF after PSARC 2007/177 > >> is putback. > > > > How are the chap secrets currently protected ? > Currently it is stored in a file readonly by root. > > > > In the 2007/177 opinion document [1], section 4.5, it states that care > > needs to be taken when using the facility to store secrets. Does > > conversion weaken the existing security ? > No, it does not weaken the existing security. I think that's a matter of debate. See the 2007/177 opinion. I wouldn't just brush it off. It may mean that "protected" clear text is comingled with unprotected public information. See Bill's mail relative to Storing Reusable Passwords. > > Does it matter ? > It does matter when a user chose to use CHAP SECRET for their system. > > > > What is the RBAC authorisation that will be used with the 2007/177 > > facility to protect the properties used to store the chap secrets ? > The iSCSI daemon uses user credential to verify user accessibility to > the iSCSI configuration database. I believe the question here is how does the proposed service (manifest) comply with the SMF Policy. In particular to value, action, and read (dependent on 2007/177) authorizations. http://opensolaris.org/os/community/arc/policies/SMF-policy/ > > What RBAC profile is that authorisation in by default ? > The default is PRIV_SYS_CONFIG. sys_config is a privilege not an authorization. Are you saying that the method context will be using a Rights Profile reference? IMO, more detail is needed in the spec for this case. Gary.. From sommerfeld@sun.com Wed Jul 25 13:21:58 2007 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 l6PKLwsg020194 for ; Wed, 25 Jul 2007 13:21:58 -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 l6PKJeYA026314; Wed, 25 Jul 2007 13:19:50 -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 <0JLR00I2P4H12S00@brm-avmta-1.central.sun.com>; Wed, 25 Jul 2007 14:19:49 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR00AOT4H0UQC0@brm-avmta-1.central.sun.com>; Wed, 25 Jul 2007 14:19:48 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l6PKJi3g002726; Wed, 25 Jul 2007 16:19:44 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6PKJiip026893; Wed, 25 Jul 2007 16:19:44 -0400 (EDT) Date: Wed, 25 Jul 2007 16:19:43 -0400 From: Bill Sommerfeld Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <46A7724B.5010804@sun.com> To: tim szeto Cc: Darren J Moffat , Kenneth Davis , PSARC-ext@sun.com, ChrisL Message-id: <1185394783.25605.30.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46A678D8.8060603@sun.com> <46A714E7.3010905@Sun.COM> <46A7724B.5010804@sun.com> Status: RO Content-Length: 640 On Wed, 2007-07-25 at 09:54 -0600, tim szeto wrote: > > In the 2007/177 opinion document [1], section 4.5, it states that care > > needs to be taken when using the facility to store secrets. Does > > conversion weaken the existing security ? > No, it does not weaken the existing security. but does the existing system actually meet our current best practices for storing sensitive keying material in files? no. I think we (PSARC) screwed up when we approved the iSCSI target case with a cleartext CHAP secret comingled with the rest of its config. we have an opportunity to improve things here with minimal effort. - Bill From Nicolas.Williams@Sun.COM Wed Jul 25 13:49:25 2007 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 l6PKnOZB020818 for ; Wed, 25 Jul 2007 13:49:24 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6PKl9fX001714; Wed, 25 Jul 2007 21:47:14 +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 <0JLR00J035QPN900@brm-avmta-1.central.sun.com>; Wed, 25 Jul 2007 14:47:13 -0600 (MDT) Received: from localhost.east.sun.com ([129.148.19.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR00IXG5QNPQ00@brm-avmta-1.central.sun.com>; Wed, 25 Jul 2007 14:47:12 -0600 (MDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l6PKi5r7002540; Wed, 25 Jul 2007 15:44:06 -0500 (CDT) Received: (from nico@localhost) by localhost.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l6PKi5Ns002539; Wed, 25 Jul 2007 15:44:05 -0500 (CDT) Date: Wed, 25 Jul 2007 15:44:04 -0500 From: Nico Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <1185325357.20267.126.camel@thunk> To: Bill Sommerfeld Cc: "Mark A. Carlson" , Kenneth Davis , psarc-ext@Sun.COM, Tim Szeto Message-id: <20070725204404.GA2512@Sun.COM> 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: <46A678D8.8060603@sun.com> <1185325357.20267.126.camel@thunk> X-Authentication-warning: localhost.east.sun.com: nico set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 954 I think we must distinguish between user and system passwords, particularly randomly generated system passwords (and, therefore, indistiguishable from other secrets that Solaris stores without additional protection). For example, Solaris Kerberos stores keys (in /etc/krb5/krb5.keytab) derived from a randomly-generated string of characters. Storing the inut to that key derivation function instead would have equivalent security properties. If we said "no, you must store such a password encrypted in some randomly generated key which is stored locally as well" then all we've done is scrmable that password, which adds no value, because the encryption key would be available to privileged users. Non-randomly generated systems passwords are another story -- those might relate to user passwords (because humans aren't very good at picking good passwords that are unrelated in form to other unrelated passwords used by the same person(s). Nico -- From sommerfeld@sun.com Wed Jul 25 14:16:33 2007 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 l6PLGWl2022438 for ; Wed, 25 Jul 2007 14:16:33 -0700 (PDT) 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 l6PLE6NF013782; Thu, 26 Jul 2007 05:14:24 +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 <0JLR00G236ZZRA00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jul 2007 14:14:23 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR006I26ZY1BB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jul 2007 14:14:23 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6PLELd4027616; Wed, 25 Jul 2007 17:14:21 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6PLEL94027063; Wed, 25 Jul 2007 17:14:21 -0400 (EDT) Date: Wed, 25 Jul 2007 17:14:20 -0400 From: Bill Sommerfeld Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <20070725204404.GA2512@Sun.COM> To: Nico Cc: "Mark A. Carlson" , Kenneth Davis , psarc-ext@sun.com, Tim Szeto Message-id: <1185398060.25605.45.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46A678D8.8060603@sun.com> <1185325357.20267.126.camel@thunk> <20070725204404.GA2512@Sun.COM> Status: RO Content-Length: 762 On Wed, 2007-07-25 at 15:44 -0500, Nico wrote: > If we said "no, you must store such a password > encrypted in some randomly generated key which is stored locally as > well" then all we've done is scrmable that password, which adds no > value, because the encryption key would be available to privileged > users. The encryption framework now supports encryption tokens with an embedded keystore; this works today with both smartcards and with several cryptoaccelerators (SCA4000, SCA6000). And, if we ever get TPM drivers, we'll have a disclosure-resistant keystore available on most of our new systems. use of a key-encrypting-key sealed in a keystore to protect values like the CHAP secret will improve our resistance to a bunch of attacks. - Bill From Nicolas.Williams@sun.com Wed Jul 25 14:33:46 2007 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 l6PLXkIt022749 for ; Wed, 25 Jul 2007 14:33:46 -0700 (PDT) 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 l6PLVa9n051096; Wed, 25 Jul 2007 15:31:37 -0600 (MDT) 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 <0JLR00M0N7SO0K00@brm-avmta-1.central.sun.com>; Wed, 25 Jul 2007 15:31:36 -0600 (MDT) Received: from localhost.east.sun.com ([129.148.19.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR00IE47SMPO30@brm-avmta-1.central.sun.com>; Wed, 25 Jul 2007 15:31:35 -0600 (MDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l6PLSTEp002614; Wed, 25 Jul 2007 16:28:30 -0500 (CDT) Received: (from nico@localhost) by localhost.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l6PLST7c002613; Wed, 25 Jul 2007 16:28:29 -0500 (CDT) Date: Wed, 25 Jul 2007 16:28:28 -0500 From: Nico Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <1185398060.25605.45.camel@thunk> To: Bill Sommerfeld Cc: "Mark A. Carlson" , Kenneth Davis , psarc-ext@sun.com, Tim Szeto Message-id: <20070725212828.GE2512@Sun.COM> 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: <46A678D8.8060603@sun.com> <1185325357.20267.126.camel@thunk> <20070725204404.GA2512@Sun.COM> <1185398060.25605.45.camel@thunk> X-Authentication-warning: localhost.east.sun.com: nico set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1340 On Wed, Jul 25, 2007 at 05:14:20PM -0400, Bill Sommerfeld wrote: > On Wed, 2007-07-25 at 15:44 -0500, Nico wrote: > > If we said "no, you must store such a password > > encrypted in some randomly generated key which is stored locally as > > well" then all we've done is scrmable that password, which adds no > > value, because the encryption key would be available to privileged > > users. > > The encryption framework now supports encryption tokens with an embedded > keystore; this works today with both smartcards and with several > cryptoaccelerators (SCA4000, SCA6000). Agreed, but our policy does allow us to do the sorts of things with do with DH and Kerberos where we just store the secret without any additional encryption. I don't see what is qualitatively different here about the iSCSI CHAP secret (provided it's randomly generated). > And, if we ever get TPM drivers, we'll have a disclosure-resistant > keystore available on most of our new systems. Most? I hope so! > use of a key-encrypting-key sealed in a keystore to protect values like > the CHAP secret will improve our resistance to a bunch of attacks. But this sounds like a new requirement. (Which, incidentally, I don't oppose, but perhaps we'd want an API for doing this that hides all the details from the app and which is available to all similar apps.) From Tim.Szeto@Sun.COM Wed Jul 25 15:10:08 2007 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 l6PMA7KE024002 for ; Wed, 25 Jul 2007 15:10:07 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6PM7fj4029789; Wed, 25 Jul 2007 23:07:58 +0100 (BST) 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 <0JLR00H019H7W100@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jul 2007 15:07:55 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR00BDO9H6EJ90@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jul 2007 15:07:54 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6PM7ss8013389; Wed, 25 Jul 2007 22:07:54 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLR006019GIFI00@mail-amer.sun.com> (original mail from Tim.Szeto@Sun.COM) ; Wed, 25 Jul 2007 16:07:54 -0600 (MDT) Received: from [172.20.58.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLR00IDD9H5C904@mail-amer.sun.com>; Wed, 25 Jul 2007 16:07:53 -0600 (MDT) Date: Wed, 25 Jul 2007 16:07:02 -0600 From: tim szeto Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <200707251952.l6PJqops007576@marduk.eng.sun.com> Sender: Tim.Szeto@Sun.COM To: Gary Winiger Cc: Darren.Moffat@Sun.COM, Chris.Liu@Sun.COM, Kenneth.Davis@Sun.COM, PSARC-ext@Sun.COM, Mark.Carlson@Sun.COM, Keith M Wesolowski , Bill Sommerfeld Message-id: <46A7C986.4040001@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: <200707251952.l6PJqops007576@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 2689 Gary, Gary Winiger wrote: >>>> The property CHAP SECRETS is converted to SCF after PSARC 2007/177 >>>> is putback. >>>> >>> How are the chap secrets currently protected ? >>> >> Currently it is stored in a file readonly by root. >> >>> In the 2007/177 opinion document [1], section 4.5, it states that care >>> needs to be taken when using the facility to store secrets. Does >>> conversion weaken the existing security ? >>> >> No, it does not weaken the existing security. >> > > I think that's a matter of debate. See the 2007/177 opinion. > I wouldn't just brush it off. It may mean that "protected" > clear text is comingled with unprotected public information. > See Bill's mail relative to Storing Reusable Passwords. > Our implementation will have both protected and non-protected properties when we implement PSARC 2007/177. My understanding of PSARC 2007/177 is that the protected property will not be visible to non privileged user. Why do we need to encrypt the CHAP SECRET if it's protected? Keith, is this true? > >>> Does it matter ? >>> >> It does matter when a user chose to use CHAP SECRET for their system. >> >>> What is the RBAC authorisation that will be used with the 2007/177 >>> facility to protect the properties used to store the chap secrets ? >>> >> The iSCSI daemon uses user credential to verify user accessibility to >> the iSCSI configuration database. >> > > I believe the question here is how does the proposed service > (manifest) comply with the SMF Policy. In particular to > value, action, and read (dependent on 2007/177) authorizations. > > http://opensolaris.org/os/community/arc/policies/SMF-policy/ > > Here's the start/stop method for the iscsi SMF manifest: >>> What RBAC profile is that authorisation in by default ? >>> >> The default is PRIV_SYS_CONFIG. >> > > sys_config is a privilege not an authorization. Are you saying > that the method context will be using a Rights Profile reference? > > IMO, more detail is needed in the spec for this case. > Does the above SMF manifest answers your question? -tim > Gary.. > From Nicolas.Williams@sun.com Wed Jul 25 15:15:13 2007 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 l6PMFDJP024044 for ; Wed, 25 Jul 2007 15:15:13 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6PMA3MB000350; Wed, 25 Jul 2007 23:13:03 +0100 (BST) 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 <0JLR00I0B9PQ8N00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jul 2007 15:13:02 -0700 (PDT) Received: from localhost.east.sun.com ([129.148.19.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR00BUF9PPEF80@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jul 2007 15:13:01 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l6PM9skT001847; Wed, 25 Jul 2007 17:09:55 -0500 (CDT) Received: (from nico@localhost) by localhost.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l6PM9rCb001846; Wed, 25 Jul 2007 17:09:53 -0500 (CDT) Date: Wed, 25 Jul 2007 17:09:53 -0500 From: Nico Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <20070725212828.GE2512@Sun.COM> To: Bill Sommerfeld Cc: "Mark A. Carlson" , Kenneth Davis , psarc-ext@sun.com, Tim Szeto Message-id: <20070725220952.GA1801@Sun.COM> 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: <46A678D8.8060603@sun.com> <1185325357.20267.126.camel@thunk> <20070725204404.GA2512@Sun.COM> <1185398060.25605.45.camel@thunk> <20070725212828.GE2512@Sun.COM> X-Authentication-warning: localhost.east.sun.com: nico set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 213 Of course, if this CHAP secret is being stored in SMF properties then, as I recall from the SMF sensitive prop case (2007/177), the secret would have to be encrypted and the key not stored in SMF. Is that right? From Keith.Wesolowski@sun.com Wed Jul 25 15:23:56 2007 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 l6PMNtjL024208 for ; Wed, 25 Jul 2007 15:23:55 -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 l6PMLf2H063070; Wed, 25 Jul 2007 16:21:42 -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 <0JLR00I0BA46NI00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jul 2007 15:21:42 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR00BTMA45ERA0@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jul 2007 15:21:41 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6PMLfB3987395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jul 2007 15:21:41 -0700 (PDT) Received: (from wesolows@localhost) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1/Submit) id l6PMLfxJ987394; Wed, 25 Jul 2007 15:21:41 -0700 (PDT) Date: Wed, 25 Jul 2007 15:21:40 -0700 From: Keith M Wesolowski Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <46A7C986.4040001@sun.com> To: tim szeto Cc: Gary Winiger , Darren.Moffat@sun.com, Chris.Liu@sun.com, Kenneth.Davis@sun.com, PSARC-ext@sun.com, Mark.Carlson@sun.com, Bill Sommerfeld Message-id: <20070725222140.GD930656@sun.com> 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: <200707251952.l6PJqops007576@marduk.eng.sun.com> <46A7C986.4040001@sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1711 On Wed, Jul 25, 2007 at 04:07:02PM -0600, tim szeto wrote: > > I think that's a matter of debate. See the 2007/177 opinion. > > I wouldn't just brush it off. It may mean that "protected" > > clear text is comingled with unprotected public information. > > See Bill's mail relative to Storing Reusable Passwords. > > > Our implementation will have both protected and non-protected properties > when we implement PSARC 2007/177. > > My understanding of PSARC 2007/177 is that the protected property will > not be visible to > non privileged user. Why do we need to encrypt the CHAP SECRET if > it's protected? > > Keith, is this true? You are correct that, if used correctly, the feature described by 2007/177 will prevent any process from obtaining the value of any property in the group unless that process meets one of the following criteria: - it has an effective privilege set containing all privileges available in the zone (or on the system), or - its effective user has one or more of the authorizations listed in the read_authorization or value_authorization properties for that property group. See my changes to smf_security(5). As far as I'm concerned, that implementation is sufficient for protecting any property group. However, some ARC members raised concerns about that level of protection, and the language in the opinion (with which I am not taking issue) reflects those concerns. You need to continue seeking their guidance to determine what, if any, additional measures are needed to protect the specific piece(s) of data you are working with. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" From gww@eng.sun.com Wed Jul 25 15:42:42 2007 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 l6PMgfWG024401 for ; Wed, 25 Jul 2007 15:42:41 -0700 (PDT) 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 l6PMeKo7020969; Thu, 26 Jul 2007 06:40: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 <0JLR00205AZJ2J00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jul 2007 15:40:31 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR00KKWAZIM180@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jul 2007 15:40:30 -0700 (PDT) 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 l6PMeRP0007645; Wed, 25 Jul 2007 15:40:27 -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 l6PMi602008005; Wed, 25 Jul 2007 15:44:06 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l6PMi6kH008004; Wed, 25 Jul 2007 15:44:06 -0700 (PDT) Date: Wed, 25 Jul 2007 15:44:06 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] To: gww@eng.sun.com, Tim.Szeto@sun.com Cc: Darren.Moffat@sun.com, Chris.Liu@sun.com, Kenneth.Davis@sun.com, PSARC-ext@sun.com, Mark.Carlson@sun.com, Keith.Wesolowski@sun.com, sommerfeld@sun.com Message-id: <200707252244.l6PMi6kH008004@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1708 > Keith, is this true? That's correct and that's not the point. See Bill's comments and the stored file password policy. The point is to explain why it is safe to have a clear text shared secret saved in the file system. Is it possible to do better? The model of shadow(4) is to store a hash and protect the hash from access. > > I believe the question here is how does the proposed service > > (manifest) comply with the SMF Policy. In particular to > > value, action, and read (dependent on 2007/177) authorizations. > > > > http://opensolaris.org/os/community/arc/policies/SMF-policy/ > > user='root' > group='sys' > > privileges='basic,sys_config,net_rawaccess,sys_mount,file_dac_write,sys_devices' > /> > > > > >>> What RBAC profile is that authorisation in by default ? > >>> > >> The default is PRIV_SYS_CONFIG. > >> > > > > sys_config is a privilege not an authorization. Are you saying > > that the method context will be using a Rights Profile reference? > > > > IMO, more detail is needed in the spec for this case. > > > Does the above SMF manifest answers your question? No, the question is about authorizations, not the method context. Is the policy not clear about authorizations? Please suggest words to improve the clarity. But, since you exposed the method context, why is uid 0 required? why won't noaccess do? why are basic privileges required? If uid 0 is required, why is file_dac_write required? Gary.. From gww@eng.sun.com Wed Jul 25 15:45:09 2007 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 l6PMj8KR024437 for ; Wed, 25 Jul 2007 15:45:09 -0700 (PDT) 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 l6PMgrk1021751; Thu, 26 Jul 2007 06:43:00 +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 <0JLR00205B3MTT00@brm-avmta-1.central.sun.com>; Wed, 25 Jul 2007 16:42:58 -0600 (MDT) 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 <0JLR00IOTB3LPL50@brm-avmta-1.central.sun.com>; Wed, 25 Jul 2007 16:42:57 -0600 (MDT) 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 l6PMgs2S007839; Wed, 25 Jul 2007 15:42:54 -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 l6PMkXZV008015; Wed, 25 Jul 2007 15:46:33 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l6PMkXNs008014; Wed, 25 Jul 2007 15:46:33 -0700 (PDT) Date: Wed, 25 Jul 2007 15:46:33 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] To: Tim.Szeto@sun.com, Keith.Wesolowski@sun.com Cc: gww@eng.sun.com, Darren.Moffat@sun.com, Chris.Liu@sun.com, Kenneth.Davis@sun.com, PSARC-ext@sun.com, Mark.Carlson@sun.com, sommerfeld@sun.com Message-id: <200707252246.l6PMkXNs008014@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 550 > However, some ARC members raised concerns about that level of > protection, and the language in the opinion (with which I am not > taking issue) reflects those concerns. You need to continue seeking > their guidance to determine what, if any, additional measures are > needed to protect the specific piece(s) of data you are working with. Indeed that's the point. What's the risk of exposing this clear text information? How could it be better protected? ... A protected property may be good enough. The point is to ensure it is. Gary.. From Tim.Szeto@sun.com Wed Jul 25 16:15:47 2007 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 l6PNFkO3025494 for ; Wed, 25 Jul 2007 16:15:47 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6PNDbcN017578; Thu, 26 Jul 2007 00:13:37 +0100 (BST) 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 <0JLR00503CIOLK00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jul 2007 16:13:36 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR00KR6CIOM3C0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jul 2007 16:13:36 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6PNDaGU027845; Wed, 25 Jul 2007 23:13:36 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLR00D01C3CFV00@mail-amer.sun.com> (original mail from Tim.Szeto@Sun.COM) ; Wed, 25 Jul 2007 17:13:36 -0600 (MDT) Received: from [172.20.58.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLR00C5ICINGR44@mail-amer.sun.com>; Wed, 25 Jul 2007 17:13:36 -0600 (MDT) Date: Wed, 25 Jul 2007 17:12:45 -0600 From: tim szeto Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <1185325357.20267.126.camel@thunk> Sender: Tim.Szeto@sun.com To: Bill Sommerfeld Cc: "Mark A. Carlson" , psarc-ext@sun.com, Kenneth Davis , ChrisL Message-id: <46A7D8ED.3050408@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: <46A678D8.8060603@sun.com> <1185325357.20267.126.camel@thunk> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 1115 Bill Sommerfeld wrote: > On Tue, 2007-07-24 at 16:10 -0600, Mark A. Carlson wrote: > >> Issue >> ====== >> The property CHAP SECRETS is converted to SCF after PSARC 2007/177 >> is putback. >> > > since no details are provided I'm assuming this means there will be > another case which specifies this. > Updated scf_design with detail of the CHAP SECRET implementation. -tim > I can't find a reference in the case materials to the original iSCSI > target case, but I think we screwed up when we approved the original > spec which stored the chap secret in the common config file, as this > clashes with the spirit of the "Storing Reusable Passwords on a > Filesystem" Best Practice; see: > > http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp > > this recommends the use of additional protections for sensitive values > stored in the filesystem; because 2007/177 merely provides an access > control mechanism and not any additional mechanisms (such as > encryption). > > there are unfortunately no really good solutions here; see the current > draft 2007/177 opinion for specifics. > > > > > From Chris.Liu@Sun.COM Wed Jul 25 17:09:39 2007 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 l6Q09cNj026449 for ; Wed, 25 Jul 2007 17:09:38 -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 l6Q07PFA026289; Thu, 26 Jul 2007 08:07:29 +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 <0JLR00007F0ELO00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jul 2007 17:07:26 -0700 (PDT) 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 <0JLR00BIZF0AEPD0@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Jul 2007 17:07:25 -0700 (PDT) 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 l6Q07MKc027925; Thu, 26 Jul 2007 00:07:22 +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 <0JLR00901ETREU00@mail-apac.sun.com> (original mail from Chris.Liu@Sun.COM) ; Thu, 26 Jul 2007 08:07:22 +0800 (SGT) Received: from [129.158.148.29] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLR0002MF018I01@mail-apac.sun.com>; Thu, 26 Jul 2007 08:07:22 +0800 (SGT) Date: Thu, 26 Jul 2007 08:07:10 +0800 From: Chris Liu Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <200707252244.l6PMi6kH008004@marduk.eng.sun.com> Sender: Chris.Liu@Sun.COM To: Gary Winiger Cc: Tim.Szeto@Sun.COM, Darren.Moffat@Sun.COM, Kenneth.Davis@Sun.COM, PSARC-ext@Sun.COM, Mark.Carlson@Sun.COM, Keith.Wesolowski@Sun.COM, sommerfeld@Sun.COM Message-id: <46A7E5AE.4050700@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: <200707252244.l6PMi6kH008004@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061110) Status: RO Content-Length: 3256 Gary, I would like to answer the first question here. IMO, model of shadow(4) could not be applied here. Here is my understanding of shadow: 1. System stores encrypted password, say E(P). 2. User login with input password, Pi. 3. System calculates E(Pi) from Pi, and compares E(p) and E(pi). The function E() is an one-way encryption algorithm, so no one needs to calculate the original plain text P. Under CHAP protocol, the System does authentication in this way: 1. System has secret Ss, and generates challenge Cs to User. 2. User calculates a value from challenge and its own secret Sc, say V(Cs, Sc) 3. System calculates a value from challenge and Ss, say V(Cs, Ss) 4. User responses and System compares two values. In this module, it's better to let both User and System know the original plain text of secret. If System stores secret Ss in encrypted mode, say E(Ss). What encryption algorithm should System choose? 1. one-way algorithm? no, if System is only aware of E(Ss) and does not know Ss in plain text. System is unable to calculate V(Cs, Ss) later. 2. two-way algorithm? in that case, System has to store the key somewhere to decrypt E(Ss), that will be another problem to securely save the key. To sum up, System has to be aware of the plain-text secret so encryption is not necessary. Protection from being read by non-privileged user is sufficient. Thanks, -Chris Gary Winiger wrote: >> Keith, is this true? >> > > That's correct and that's not the point. See Bill's comments > and the stored file password policy. The point is to explain > why it is safe to have a clear text shared secret saved in > the file system. Is it possible to do better? > The model of shadow(4) is to store a hash and protect the hash > from access. > > >>> I believe the question here is how does the proposed service >>> (manifest) comply with the SMF Policy. In particular to >>> value, action, and read (dependent on 2007/177) authorizations. >>> >>> http://opensolaris.org/os/community/arc/policies/SMF-policy/ >>> > > >> >> > user='root' >> group='sys' >> >> privileges='basic,sys_config,net_rawaccess,sys_mount,file_dac_write,sys_devices' >> /> >> >> >> >> >>>>> What RBAC profile is that authorisation in by default ? >>>>> >>>>> >>>> The default is PRIV_SYS_CONFIG. >>>> >>>> >>> >>> sys_config is a privilege not an authorization. Are you saying >>> that the method context will be using a Rights Profile reference? >>> >>> IMO, more detail is needed in the spec for this case. >>> >>> >> Does the above SMF manifest answers your question? >> > > No, the question is about authorizations, not the method context. > Is the policy not clear about authorizations? Please suggest words > to improve the clarity. > > But, since you exposed the method context, why is uid 0 required? > why won't noaccess do? why are basic privileges required? > If uid 0 is required, why is file_dac_write required? > > Gary.. > From sommerfeld@sun.com Wed Jul 25 18:08:26 2007 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 l6Q18PFD028529 for ; Wed, 25 Jul 2007 18:08:25 -0700 (PDT) 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 l6Q16AGK019833; Thu, 26 Jul 2007 09:06: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 <0JLR00H01HQFVK00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jul 2007 18:06:15 -0700 (PDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JLR007Q6HQEFJD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Jul 2007 18:06:14 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l6Q168nG010331; Wed, 25 Jul 2007 21:06:08 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6Q168nf028004; Wed, 25 Jul 2007 21:06:08 -0400 (EDT) Date: Wed, 25 Jul 2007 21:06:07 -0400 From: Bill Sommerfeld Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <46A7E5AE.4050700@Sun.COM> To: Chris Liu Cc: Gary Winiger , Tim.Szeto@sun.com, Darren.Moffat@sun.com, Kenneth.Davis@sun.com, PSARC-ext@sun.com, mark.carlson@sun.com, keith.wesolowski@sun.com Message-id: <1185411967.25605.102.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200707252244.l6PMi6kH008004@marduk.eng.sun.com> <46A7E5AE.4050700@Sun.COM> Status: RO Content-Length: 429 On Thu, 2007-07-26 at 08:07 +0800, Chris Liu wrote: > To sum up, System has to be aware of the plain-text secret This is true > so encryption is not necessary. This does not follow, given that the solaris encryption framework, in combination with devices supporting a hardware keystore, is now capable of storing encryption keys such that they can be used, but not disclosed outside the encryption token. - Bill From Chris.Liu@sun.com Thu Jul 26 16:09:05 2007 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 l6QN94gO003716 for ; Thu, 26 Jul 2007 16:09:04 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6QN6XPF006319; Fri, 27 Jul 2007 00:06:53 +0100 (BST) 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 <0JLT00B036VF8K00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 26 Jul 2007 16:06:51 -0700 (PDT) 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 <0JLT00AGN6VD9EA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 26 Jul 2007 16:06:50 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6QN6n2b009829; Thu, 26 Jul 2007 23:06:49 +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 <0JLT006016LX0700@mail-apac.sun.com> (original mail from Chris.Liu@Sun.COM) ; Fri, 27 Jul 2007 07:06:49 +0800 (SGT) Received: from [129.158.148.29] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLT0002C6VB8IX2@mail-apac.sun.com>; Fri, 27 Jul 2007 07:06:48 +0800 (SGT) Date: Fri, 27 Jul 2007 07:06:44 +0800 From: Chris Liu Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <1185411967.25605.102.camel@thunk> Sender: Chris.Liu@sun.com To: Bill Sommerfeld Cc: Gary Winiger , Tim.Szeto@sun.com, Darren.Moffat@sun.com, Kenneth.Davis@sun.com, PSARC-ext@sun.com, Mark.Carlson@sun.com, Keith.Wesolowski@sun.com Message-id: <46A92904.4070307@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: <200707252244.l6PMi6kH008004@marduk.eng.sun.com> <46A7E5AE.4050700@Sun.COM> <1185411967.25605.102.camel@thunk> User-Agent: Thunderbird 1.5.0.8 (X11/20061110) Status: RO Content-Length: 793 Hi Bill, Could you please recommend some document of the hardware keystore technology? Does it require any extra hardware? If it is a two-way mechanism (like encrypt/decrypt), I dont see any chance to prevent the disclosure. IMO, it not even stronger than RBAC. thanks, -Chris Bill Sommerfeld wrote: > On Thu, 2007-07-26 at 08:07 +0800, Chris Liu wrote: > >> To sum up, System has to be aware of the plain-text secret >> > > This is true > > >> so encryption is not necessary. >> > > This does not follow, given that the solaris encryption framework, in > combination with devices supporting a hardware keystore, is now capable > of storing encryption keys such that they can be used, but not disclosed > outside the encryption token. > > - Bill > > > > > > > From gww@eng.sun.com Tue Jul 31 12:35:28 2007 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 l6VJZRqZ001038 for ; Tue, 31 Jul 2007 12:35:28 -0700 (PDT) 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 l6VJXBo7005508; Wed, 1 Aug 2007 03:33:13 +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 <0JM20020N6BC5200@nwk-avmta-1.sfbay.Sun.COM>; Tue, 31 Jul 2007 12:33:12 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM200HZC6B84NE0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 31 Jul 2007 12:33:08 -0700 (PDT) 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 l6VJX5Rt028478; Tue, 31 Jul 2007 12:33:05 -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 l6VJarJI015608; Tue, 31 Jul 2007 12:36:53 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l6VJarfU015607; Tue, 31 Jul 2007 12:36:53 -0700 (PDT) Date: Tue, 31 Jul 2007 12:36:53 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] To: Chris.Liu@Sun.COM, gww@eng.sun.com Cc: Darren.Moffat@Sun.COM, Keith.Wesolowski@Sun.COM, Kenneth.Davis@Sun.COM, Mark.Carlson@Sun.COM, PSARC-ext@Sun.COM, Tim.Szeto@Sun.COM, sommerfeld@Sun.COM Message-id: <200707311936.l6VJarfU015607@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 704 > I would like to answer the first question here. Unfortunately you didn't. Yes I understand the protocol. You missed the analogy. shadow(4) is not only read protected, but it's content is not in clear text. That's the point of the SAC policy on passwords in the file system. It's not substatively different relative to the repository. > To sum up, System has to be aware of the plain-text secret so encryption > is not necessary. Protection from being read by non-privileged user is > sufficient. The point (and I believe Bill's as well) is to understand this and provide some compelling rationale why it's OK to not provide stronger protection for this plain text shared secret. Gary.. From gww@eng.sun.com Tue Jul 31 12:37:13 2007 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 l6VJbCxP001086 for ; Tue, 31 Jul 2007 12:37:12 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l6VJYpWx003107; Tue, 31 Jul 2007 20:34:58 +0100 (BST) 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 <0JM2004056E9G600@nwk-avmta-2.sfbay.sun.com>; Tue, 31 Jul 2007 12:34:57 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM2001YA6E9R320@nwk-avmta-2.sfbay.sun.com>; Tue, 31 Jul 2007 12:34:57 -0700 (PDT) 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 l6VJYrHY028630; Tue, 31 Jul 2007 12:34:53 -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 l6VJcgTI015637; Tue, 31 Jul 2007 12:38:42 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l6VJcgCh015636; Tue, 31 Jul 2007 12:38:42 -0700 (PDT) Date: Tue, 31 Jul 2007 12:38:42 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] To: Tim.Szeto@sun.com, gww@eng.sun.com Cc: Chris.Liu@sun.com, Darren.Moffat@sun.com, Keith.Wesolowski@sun.com, Kenneth.Davis@sun.com, Mark.Carlson@sun.com, PSARC-ext@sun.com, sommerfeld@sun.com Message-id: <200707311938.l6VJcgCh015636@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1473 > > > I believe the question here is how does the proposed service > > > (manifest) comply with the SMF Policy. In particular to > > > value, action, and read (dependent on 2007/177) authorizations. > > > > > > http://opensolaris.org/os/community/arc/policies/SMF-policy/ > > > > > > user='root' > > group='sys' > > > > privileges='basic,sys_config,net_rawaccess,sys_mount,file_dac_write,sys_devices' > > /> > > > > > > > > >>> What RBAC profile is that authorisation in by default ? > > >>> > > >> The default is PRIV_SYS_CONFIG. > > >> > > > > > > sys_config is a privilege not an authorization. Are you saying > > > that the method context will be using a Rights Profile reference? > > > > > > IMO, more detail is needed in the spec for this case. > > > > > Does the above SMF manifest answers your question? > > No, the question is about authorizations, not the method context. > Is the policy not clear about authorizations? Please suggest words > to improve the clarity. > > But, since you exposed the method context, why is uid 0 required? > why won't noaccess do? why are basic privileges required? > If uid 0 is required, why is file_dac_write required? Is this going to be answered? Gary.. From Tim.Szeto@sun.com Tue Jul 31 15:46:02 2007 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 l6VMk1ue011105 for ; Tue, 31 Jul 2007 15:46:02 -0700 (PDT) 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 l6VMhju2009239; Wed, 1 Aug 2007 06:43:47 +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 <0JM200J0DF4XME00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 31 Jul 2007 15:43:45 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM200FUJF4VJA10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 31 Jul 2007 15:43:44 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6VMhh8Q026925; Tue, 31 Jul 2007 22:43:43 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JM200F01EU1D500@mail-amer.sun.com> (original mail from Tim.Szeto@Sun.COM) ; Tue, 31 Jul 2007 16:43:43 -0600 (MDT) Received: from [172.20.58.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JM2003X4F4ULEQ6@mail-amer.sun.com>; Tue, 31 Jul 2007 16:43:42 -0600 (MDT) Date: Tue, 31 Jul 2007 16:42:43 -0600 From: tim szeto Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <200707311938.l6VJcgCh015636@marduk.eng.sun.com> Sender: Tim.Szeto@sun.com To: Gary Winiger Cc: Chris.Liu@sun.com, Darren.Moffat@sun.com, Keith.Wesolowski@sun.com, Kenneth.Davis@sun.com, Mark.Carlson@sun.com, PSARC-ext@sun.com, sommerfeld@sun.com Message-id: <46AFBAE3.8070209@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: <200707311938.l6VJcgCh015636@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 2146 Gary, Sorry for the long delay, I'm trying to understand how RBAC and SMF authorization work. Gary Winiger wrote: >>>> I believe the question here is how does the proposed service >>>> (manifest) comply with the SMF Policy. In particular to >>>> value, action, and read (dependent on 2007/177) authorizations. >>>> >>>> http://opensolaris.org/os/community/arc/policies/SMF-policy/ >>>> >>> >>> >> user='root' >>> group='sys' >>> >>> privileges='basic,sys_config,net_rawaccess,sys_mount,file_dac_write,sys_devices' >>> /> >>> >>> >>> >>> >>>>>> What RBAC profile is that authorisation in by default ? >>>>>> >>>>>> >>>>> The default is PRIV_SYS_CONFIG. >>>>> >>>>> >>>> >>>> sys_config is a privilege not an authorization. Are you saying >>>> that the method context will be using a Rights Profile reference? >>>> >>>> IMO, more detail is needed in the spec for this case. >>>> Currently there is no authorization for the iSCSI target. >>>> >>>> >>> Does the above SMF manifest answers your question? >>> >> No, the question is about authorizations, not the method context. >> Is the policy not clear about authorizations? Please suggest words >> to improve the clarity. >> >> The original author of this manifest is no longer at Sun, I will try to interpret why it is done this way. >> But, since you exposed the method context, why is uid required? >> This is a daemon that should only be run by root to access configuration files, backing stores (disk storage) and other resources. >> why won't noaccess do? because it cannot access resources. >> why are basic privileges required? >> I don't know, probably not needed. >> If uid 0 is required, why is file_dac_write required? >> You're right, file_dac_write is not needed. -tim > > Is this going to be answered? > > Gary.. > From Tim.Szeto@sun.com Tue Jul 31 17:45:10 2007 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 l710j9rw019618 for ; Tue, 31 Jul 2007 17:45:10 -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 l710griG016480; Wed, 1 Aug 2007 08:42:55 +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 <0JM200J03KNHTK00@nwk-avmta-2.sfbay.sun.com>; Tue, 31 Jul 2007 17:42:53 -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 <0JM200EYYKNHZH30@nwk-avmta-2.sfbay.sun.com>; Tue, 31 Jul 2007 17:42:53 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l710grNX006540; Wed, 01 Aug 2007 00:42:53 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JM200301K4WFZ00@mail-amer.sun.com> (original mail from Tim.Szeto@Sun.COM) ; Tue, 31 Jul 2007 18:42:53 -0600 (MDT) Received: from [172.20.58.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JM200C7PKNGGRE5@mail-amer.sun.com>; Tue, 31 Jul 2007 18:42:52 -0600 (MDT) Date: Tue, 31 Jul 2007 18:41:51 -0600 From: tim szeto Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <200707311936.l6VJarfU015607@marduk.eng.sun.com> Sender: Tim.Szeto@sun.com To: PSARC-ext@sun.com Cc: Gary Winiger , Chris.Liu@sun.com, Darren.Moffat@sun.com, Keith.Wesolowski@sun.com, Kenneth.Davis@sun.com, Mark.Carlson@sun.com, sommerfeld@sun.com, Nico , "iscsi-tgt-iteam@Sun.COM" Message-id: <46AFD6CF.5050109@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: <200707311936.l6VJarfU015607@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 1048 Summary of the concerns and proposed solutions for the PSARC 2007/414: Concern: Does clear text CHAP secret provides enough security? Arguments: -With the implementation of PSARC 2007/177, this should be sufficient to prevent the display of the CHAP secret to unauthorized user. Using PSARC 2007/177 we did not worsen the existing security. -RFC 1994 required a plain text CHAP secret to authenticate client. -Encrypting the CHAP secret creates similar issue with how to store the encryption key. -Sun iSCSI initiator currently stores the the CHAP secret in clear text. Concern: The iSCSI target manifest does not comply with SMF authorization. Proposal: -We will add action_authorization and value_authorization to the manifest to make it SMF authorization compliant. Issues: -The CHAP secret will be put back after PSARC 2007/177 is putback. The PSARC 2007/414 will cover the putback of the CHAP secret at a later time, and no additional case is needed. From Mark.Carlson@Sun.COM Wed Aug 1 10:21:03 2007 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 l71HL3Nu024029 for ; Wed, 1 Aug 2007 10:21:03 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l71HIeAG022942 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 1 Aug 2007 18:18:47 +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 <0JM300M0FUR9TV00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 01 Aug 2007 11:18:45 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JM3005WHUR8Y7D0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 01 Aug 2007 11:18:44 -0600 (MDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l71HIivX026234 for ; Wed, 01 Aug 2007 17:18:44 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JM300L01UAZTR00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 01 Aug 2007 11:18:44 -0600 (MDT) Received: from dhcp-usfo07-88-169.sfbay.sun.com ([129.144.88.169]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JM300327UR7LFR4@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 01 Aug 2007 11:18:44 -0600 (MDT) Date: Wed, 01 Aug 2007 11:18:43 -0600 From: "Mark A. Carlson" Subject: SCF changes for iSCSI Target PSARC/2007/414 FastTrack NEW timeout 08/07/2007 In-reply-to: <46A678D8.8060603@sun.com> Sender: Mark.Carlson@Sun.COM To: psarc-ext@Sun.COM Cc: Kenneth Davis , Tim Szeto Message-id: <46B0C073.6070200@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: <46A678D8.8060603@sun.com> User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) Status: RO Content-Length: 4853 The timeout was extended by another week for this case at PSARC today. There is a dependency on PSARC 2007/177 to converge, which was just approved. Timeout is now 08/07/2007. -- mark Mark A. Carlson wrote: > I am sponsoring this case for the iSCSI Target team. > > Timeout has been extended since not everyone saw this > this first time. > > -- mark > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2007 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > SCF changes for iSCSI Target > 1.2. Name of Document Author/Supplier: > Author: Tim Szeto > 1.3 Date of This Document: > 16 July, 2007 > 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 > > > SCF design for iSCSI target > =========================== > > High Level: > -All configuration files (target_config.xml, config.xml, param.N) are moved > to SCF. > > -Keeping the current incore XML database > -the incore database is created from the SCF (need functions to > convert SCF->incore) > -the incore database will change as follow: > -the target_config.xml, config.xml and param.N will merged into > 1 database > > -Need to convert existing configuration to SCF if old configuration files > (config.xml, target_config.xml) existed, after converting to SCF, the > old configurations are deleted. This would mean keeping some of > the existing codes that read in the configuration files and build > the incore database, and then use the tgt_dump2scf() to build the SCF. > > -All the pgroups/properties are create dynamically, the only exception > is the iscsitgt pgroup, the properties in this pgroup can be > populated with the default value on install. > > -The CLI still uses the door interface to the daemon, the mgmt > interfaces are used to create incore database and then use the > mgmt_scf interfaces to create/modify/delete the SCF database. > > -At startup a mgmt_scf function will open the SCF database and read in > the iscsitgt pgroup, and the target pgroups, the SCF data are > converted to incore database. > > -The incore database will have a new property for the target, it will > contains param propertes for each LUN. Example of an incore target > configuration: > > > t1 > > 0 > 1 > > > iqn.1986-03.com.sun:02:... > > > <0> > > 0x10000 > . > . > 039384947504 > > > <1> > > 0x10000 > . > . > 039377777504 > > > > > > > > API > === > -pgroup > -create > -modify > -delete > -find > > -property per pgroup > -create > -modify > -delete > -find > > -Find pgroup (initiator_name, tpgt_num, param_targetname_lun) > -Get properties > -convert to incore database > > Startup > ------- > -Find iscsitgt pgroup (default) > -iterate for properties in pgroup > -convert to local database > > -Iterate target_name pgroup > -iterate target property > -Find initiator_name pgroup > -iterate initiator property (iscsi_name, chap_name, chap_secret) > -Find tpgt_num group > -iterate tpgt property (ip_address) > -convert to local database > > > > Create pgroup/property > ---------------------- > -create in core database > -create new pgroup (target, initiator, tgpt, param) > -create target > -create target_name pgroup > -create local_name prop > -create iscsi_name prop > -create .... prop > -commit > -create initiator > -create initiator_name pgroup > -create local_name prop > -commit > -create tpgt > -create ip_addr prop > -commit > > Modify property > --------------- > -modify in core database > -find pgroup > -find property > -modify property > -commit > > Delete pgroup/property > ---------------------- > -delete pgroup name > -find pgroup name > -delete properties and then pgroup > -delete property on a given pgroup > -find pgroup > -find prperty > -delete property > -commit > > Find pgroup/property > -------------------- > -find pgroup name > -find property given pgroup handle > > Issue > ====== > The property CHAP SECRETS is converted to SCF after PSARC 2007/177 > is putback. > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > From gww@eng.sun.com Mon Aug 6 19:00:31 2007 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 l7720Vhu029892 for ; Mon, 6 Aug 2007 19:00:31 -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 l771wCiJ012435; Mon, 6 Aug 2007 18:58:12 -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 <0JMD00B0HS50DH00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 06 Aug 2007 18:58:12 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMD00DBES4W5R80@nwk-avmta-1.sfbay.Sun.COM>; Mon, 06 Aug 2007 18:58:08 -0700 (PDT) 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 l771w5eh009046; Mon, 06 Aug 2007 18:58:05 -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 l77222qA006474; Mon, 06 Aug 2007 19:02:02 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l77222IJ006473; Mon, 06 Aug 2007 19:02:02 -0700 (PDT) Date: Mon, 06 Aug 2007 19:02:02 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] To: PSARC-ext@Sun.COM, Tim.Szeto@Sun.COM Cc: Chris.Liu@Sun.COM, Darren.Moffat@Sun.COM, Keith.Wesolowski@Sun.COM, Kenneth.Davis@Sun.COM, Mark.Carlson@Sun.COM, Nicolas.Williams@Sun.COM, gww@eng.sun.com, iscsi-tgt-iteam@Sun.COM, sommerfeld@Sun.COM Message-id: <200708070202.l77222IJ006473@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1094 > Summary of the concerns and proposed solutions for the PSARC 2007/414: > > Concern: Does clear text CHAP secret provides enough security? I'm going to leave this one for now to get a feeling of others. > Concern: The iSCSI target manifest does not comply with SMF authorization. > Proposal: > -We will add action_authorization and value_authorization to the > manifest to make > it SMF authorization compliant. Good. Is there an updated spec showing this? Some how, I've missed the FMRI and man pages documenting it. Shouldn't this turn iscsitadm into being completely authorization driven? ;-) It would be nice to see the updated man page. > Issues: > -The CHAP secret will be put back after PSARC 2007/177 is putback. > The PSARC 2007/414 will > cover the putback of the CHAP secret at a later time, and no > additional case is needed. I'm not sure how to read this. Is this accepting a case dependency on 2007/177? Or is it saying that a two phase project is being requested. Phase 1 without CHAP, phase 2 after 177 with CHAP. Gary.. From Tim.Szeto@sun.com Tue Aug 7 10:29:55 2007 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 l77HTsB5019494 for ; Tue, 7 Aug 2007 10:29:54 -0700 (PDT) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l77HQpPK028094; Tue, 7 Aug 2007 18:27:33 +0100 (BST) 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 <0JME00303Z5WNG00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 07 Aug 2007 10:27:32 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JME00E9UZ5V22F0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 07 Aug 2007 10:27:31 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l77HRVux012907; Tue, 07 Aug 2007 17:27:31 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JME00901YX5OV00@mail-amer.sun.com> (original mail from Tim.Szeto@Sun.COM) ; Tue, 07 Aug 2007 11:27:31 -0600 (MDT) Received: from [172.20.58.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JME00C1EZ5VGSEB@mail-amer.sun.com>; Tue, 07 Aug 2007 11:27:31 -0600 (MDT) Date: Tue, 07 Aug 2007 11:26:19 -0600 From: tim szeto Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <200708070202.l77222IJ006473@marduk.eng.sun.com> Sender: Tim.Szeto@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, Chris.Liu@sun.com, Darren.Moffat@sun.com, Keith.Wesolowski@sun.com, Kenneth.Davis@sun.com, Mark.Carlson@sun.com, Nicolas.Williams@sun.com, iscsi-tgt-iteam@sun.com, sommerfeld@sun.com Message-id: <46B8AB3B.7090406@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: <200708070202.l77222IJ006473@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 1628 Gary Winiger wrote: >> Summary of the concerns and proposed solutions for the PSARC 2007/414: >> >> Concern: Does clear text CHAP secret provides enough security? >> > > I'm going to leave this one for now to get a feeling of others. > > >> Concern: The iSCSI target manifest does not comply with SMF authorization. >> Proposal: >> -We will add action_authorization and value_authorization to the >> manifest to make >> it SMF authorization compliant. >> > > Good. Is there an updated spec showing this? I updated the scf_design doc with a section on "Iscsi Target RBAC authorization". > Some how, I've > missed the FMRI and man pages documenting it. Shouldn't this > turn iscsitadm into being completely authorization driven? ;-) > No authorization is needed for iscsitadm, the cli sends the request to the daemon and the daemon verify the user credential. I don't think update to the man page is needed. > It would be nice to see the updated man page. > > >> Issues: >> -The CHAP secret will be put back after PSARC 2007/177 is putback. >> The PSARC 2007/414 will >> cover the putback of the CHAP secret at a later time, and no >> additional case is needed. >> > > I'm not sure how to read this. Is this accepting a case dependency > on 2007/177? Or is it saying that a two phase project is being > requested. Phase 1 without CHAP, phase 2 after 177 with CHAP. > We are requesting to make this a 2 phase project, and we will provide all the documents to address both phases. The 2nd phase will accept the 2007/177 dependency. > Gary.. > From Mark.Carlson@sun.com Tue Aug 7 10:40:50 2007 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 l77HeoRJ020107 for ; Tue, 7 Aug 2007 10:40:50 -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 l77HcKlm053627; Tue, 7 Aug 2007 11:38:23 -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 <0JME0042FZO4HJ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 07 Aug 2007 10:38:28 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JME003T2ZO3PZ00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 07 Aug 2007 10:38:27 -0700 (PDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l77HcRQb025757; Tue, 07 Aug 2007 17:38:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JME00E01ZLS4L00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM); Tue, 07 Aug 2007 11:38:27 -0600 (MDT) Received: from MACsMAC.local ([129.150.33.1]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JME00DE6ZO1ESQ6@mail-amer.sun.com>; Tue, 07 Aug 2007 11:38:27 -0600 (MDT) Date: Tue, 07 Aug 2007 11:38:25 -0600 From: "Mark A. Carlson" Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <46B8AB3B.7090406@sun.com> Sender: Mark.Carlson@sun.com To: Gary Winiger , PSARC-ext@sun.com, Darren.Moffat@sun.com, Nicolas.Williams@sun.com, sommerfeld@sun.com Cc: tim szeto , Chris.Liu@sun.com, keith.wesolowski@sun.com, Kenneth.Davis@sun.com, iscsi-tgt-iteam@sun.com Message-id: <46B8AE11.6060507@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: <200708070202.l77222IJ006473@marduk.eng.sun.com> <46B8AB3B.7090406@sun.com> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 1829 This fast track times out today. Does anyone need more time, or are we converging here? -- mark tim szeto wrote: > > > Gary Winiger wrote: >>> Summary of the concerns and proposed solutions for the PSARC 2007/414: >>> >>> Concern: Does clear text CHAP secret provides enough security? >>> >> >> I'm going to leave this one for now to get a feeling of others. >> >> >>> Concern: The iSCSI target manifest does not comply with SMF >>> authorization. >>> Proposal: >>> -We will add action_authorization and value_authorization to >>> the manifest to make >>> it SMF authorization compliant. >>> >> >> Good. Is there an updated spec showing this? > I updated the scf_design doc with a section on "Iscsi Target RBAC > authorization". >> Some how, I've >> missed the FMRI and man pages documenting it. Shouldn't this >> turn iscsitadm into being completely authorization driven? ;-) >> > No authorization is needed for iscsitadm, the cli sends the request to > the daemon and > the daemon verify the user credential. I don't think update to the > man page is needed. >> It would be nice to see the updated man page. >> >> >>> Issues: >>> -The CHAP secret will be put back after PSARC 2007/177 is >>> putback. The PSARC 2007/414 will >>> cover the putback of the CHAP secret at a later time, and no >>> additional case is needed. >>> >> >> I'm not sure how to read this. Is this accepting a case dependency >> on 2007/177? Or is it saying that a two phase project is being >> requested. Phase 1 without CHAP, phase 2 after 177 with CHAP. >> > We are requesting to make this a 2 phase project, and we will provide > all the documents to > address both phases. The 2nd phase will accept the 2007/177 dependency. > >> Gary.. >> From sommerfeld@sun.com Tue Aug 7 10:44:58 2007 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 l77HiwHL020142 for ; Tue, 7 Aug 2007 10:44:58 -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 l77HgcY4006587; Tue, 7 Aug 2007 10:42:38 -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 <0JME0080JZV1ZQ00@brm-avmta-1.central.sun.com>; Tue, 07 Aug 2007 11:42:37 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JME007OTZUZ3F30@brm-avmta-1.central.sun.com>; Tue, 07 Aug 2007 11:42:36 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l77HgUUC001353; Tue, 07 Aug 2007 13:42:30 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l77HgTWb021722; Tue, 07 Aug 2007 13:42:30 -0400 (EDT) Date: Tue, 07 Aug 2007 13:42:29 -0400 From: Bill Sommerfeld Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <46B8AE11.6060507@sun.com> To: "Mark A. Carlson" Cc: Gary Winiger , PSARC-ext@sun.com, Darren.Moffat@sun.com, Nicolas.Williams@sun.com, tim szeto , Chris.Liu@sun.com, keith.wesolowski@sun.com, Kenneth.Davis@sun.com, iscsi-tgt-iteam@sun.com Message-id: <1186508549.21220.2.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200708070202.l77222IJ006473@marduk.eng.sun.com> <46B8AB3B.7090406@sun.com> <46B8AE11.6060507@sun.com> Status: RO Content-Length: 297 On Tue, 2007-08-07 at 11:38 -0600, Mark A. Carlson wrote: > This fast track times out today. Does anyone need more time, > or are we converging here? Sorry, I haven't had a chance to comment on this -- my psarc cycles went to other cases last week. Can I have a couple more days? - Bill From Mark.Carlson@sun.com Tue Aug 7 10:51:38 2007 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 l77HpbEp020492 for ; Tue, 7 Aug 2007 10:51:37 -0700 (PDT) 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 l77Hn6hh003309; Wed, 8 Aug 2007 01:49:16 +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 <0JMF0090D061H400@brm-avmta-1.central.sun.com>; Tue, 07 Aug 2007 11:49:13 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMF0076F05Z3F40@brm-avmta-1.central.sun.com>; Tue, 07 Aug 2007 11:49:11 -0600 (MDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l77HnBie004491; Tue, 07 Aug 2007 17:49:11 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JME00201ZZZ8P00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM); Tue, 07 Aug 2007 11:49:11 -0600 (MDT) Received: from MACsMAC.local ([129.150.33.1]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMF0027K05YCJP3@mail-amer.sun.com>; Tue, 07 Aug 2007 11:49:11 -0600 (MDT) Date: Tue, 07 Aug 2007 11:49:09 -0600 From: "Mark A. Carlson" Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <1186508549.21220.2.camel@thunk> Sender: Mark.Carlson@sun.com To: Bill Sommerfeld Cc: Gary Winiger , PSARC-ext@sun.com, Darren.Moffat@sun.com, Nicolas.Williams@sun.com, tim szeto , Chris.Liu@sun.com, keith.wesolowski@sun.com, Kenneth.Davis@sun.com, iscsi-tgt-iteam@sun.com Message-id: <46B8B095.3090000@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_KdXYI1t4rHdHUqAeE4q1PQ)" X-PMX-Version: 5.2.0.264296 References: <200708070202.l77222IJ006473@marduk.eng.sun.com> <46B8AB3B.7090406@sun.com> <46B8AE11.6060507@sun.com> <1186508549.21220.2.camel@thunk> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 1557 This is a multi-part message in MIME format. --Boundary_(ID_KdXYI1t4rHdHUqAeE4q1PQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Timeout has been extended until Thursday. -- mark Bill Sommerfeld wrote: > On Tue, 2007-08-07 at 11:38 -0600, Mark A. Carlson wrote: > >> This fast track times out today. Does anyone need more time, >> or are we converging here? >> > > Sorry, I haven't had a chance to comment on this -- my psarc cycles went > to other cases last week. Can I have a couple more days? > > - Bill > > > --Boundary_(ID_KdXYI1t4rHdHUqAeE4q1PQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Timeout has been extended until Thursday.

-- mark

Bill Sommerfeld wrote: 
On Tue, 2007-08-07 at 11:38 -0600, Mark A. Carlson wrote:
  
This fast track times out today. Does anyone need more time,
or are we converging here?
    

Sorry, I haven't had a chance to comment on this -- my psarc cycles went
to other cases last week.  Can I have a couple more days?

					- Bill
--Boundary_(ID_KdXYI1t4rHdHUqAeE4q1PQ)-- From gww@eng.sun.com Tue Aug 7 12:23:56 2007 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 l77JNtFf022763 for ; Tue, 7 Aug 2007 12:23:56 -0700 (PDT) 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 l77JLUi3015809; Wed, 8 Aug 2007 03:21:34 +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 <0JMF00E0N4FVQC00@brm-avmta-1.central.sun.com>; Tue, 07 Aug 2007 13:21:31 -0600 (MDT) 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 <0JMF007GM4FT3FB0@brm-avmta-1.central.sun.com>; Tue, 07 Aug 2007 13:21:30 -0600 (MDT) 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 l77JLPe4018600; Tue, 07 Aug 2007 12:21:25 -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 l77JPOIU007471; Tue, 07 Aug 2007 12:25:24 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l77JPOW5007470; Tue, 07 Aug 2007 12:25:24 -0700 (PDT) Date: Tue, 07 Aug 2007 12:25:24 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] To: gww@eng.sun.com, PSARC-ext@Sun.com, Darren.Moffat@Sun.com, Nicolas.Williams@Sun.com, sommerfeld@Sun.com, Mark.Carlson@Sun.com Cc: Tim.Szeto@Sun.com, Chris.Liu@Sun.com, Keith.Wesolowski@Sun.com, Kenneth.Davis@Sun.com, iscsi-tgt-iteam@Sun.com Message-id: <200708071925.l77JPOW5007470@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 161 > This fast track times out today. Does anyone need more time, > or are we converging here? IMO there are still open issues and an ongoing discussion. Gary.. From gww@eng.sun.com Tue Aug 7 12:29:25 2007 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 l77JTPJH022869 for ; Tue, 7 Aug 2007 12:29:25 -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 l77JQueS024638; Tue, 7 Aug 2007 13:26:58 -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 <0JMF00C0R4P3L700@nwk-avmta-1.sfbay.Sun.COM>; Tue, 07 Aug 2007 12:27:03 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMF003GS4P1PW80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 07 Aug 2007 12:27:01 -0700 (PDT) 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 l77JQvM6019556; Tue, 07 Aug 2007 12:26:57 -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 l77JUuhQ007486; Tue, 07 Aug 2007 12:30:56 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l77JUu0e007485; Tue, 07 Aug 2007 12:30:56 -0700 (PDT) Date: Tue, 07 Aug 2007 12:30:56 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] To: gww@eng.sun.com, PSARC-ext@sun.com, Darren.Moffat@sun.com, Nicolas.Williams@sun.com, sommerfeld@sun.com, Mark.Carlson@sun.com Cc: Tim.Szeto@sun.com, Chris.Liu@sun.com, Keith.Wesolowski@sun.com, Kenneth.Davis@sun.com, iscsi-tgt-iteam@sun.com Message-id: <200708071930.l77JUu0e007485@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 216 > > This fast track times out today. Does anyone need more time, > > or are we converging here? > > IMO there are still open issues and an ongoing discussion. And there was a new spec announced at 1031. Gary.. From gww@eng.sun.com Wed Aug 8 10:57:28 2007 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 l78HvSEN021764 for ; Wed, 8 Aug 2007 10:57:28 -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 l78Ht8Rb008716; Wed, 8 Aug 2007 10:55:08 -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 <0JMG0030VV3W4G00@brm-avmta-1.central.sun.com>; Wed, 08 Aug 2007 11:55:08 -0600 (MDT) 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 <0JMG00E4JV3U8JE0@brm-avmta-1.central.sun.com>; Wed, 08 Aug 2007 11:55:06 -0600 (MDT) 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 l78Ht2WN026367; Wed, 08 Aug 2007 10:55:02 -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 l78Hx2Gc009006; Wed, 08 Aug 2007 10:59:02 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l78Hx2mk009005; Wed, 08 Aug 2007 10:59:02 -0700 (PDT) Date: Wed, 08 Aug 2007 10:59:02 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] To: Tim.Szeto@sun.com, gww@eng.sun.com Cc: Chris.Liu@sun.com, Darren.Moffat@sun.com, Keith.Wesolowski@sun.com, Kenneth.Davis@sun.com, Mark.Carlson@sun.com, Nicolas.Williams@sun.com, PSARC-ext@sun.com, iscsi-tgt-iteam@sun.com, sommerfeld@sun.com Message-id: <200708081759.l78Hx2mk009005@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2472 > Gary Winiger wrote: > >> Summary of the concerns and proposed solutions for the PSARC 2007/414: > >> > >> Concern: Does clear text CHAP secret provides enough security? It seems that this project is being factored to bypass this issue. See the project teams response below. Is the project complete without a CHAP secret? > > I'm going to leave this one for now to get a feeling of others. > > > > > >> Concern: The iSCSI target manifest does not comply with SMF authorization. > >> Proposal: > >> -We will add action_authorization and value_authorization to the > >> manifest to make > >> it SMF authorization compliant. > >> > > > > Good. Is there an updated spec showing this? > I updated the scf_design doc with a section on "Iscsi Target RBAC > authorization". At the code review level, I'm not sure 2. Iscsitgt service manifest will do what you want it to do. Please have the SMF folk code review your service manifest. > > Some how, I've > > missed the FMRI and man pages documenting it. Shouldn't this > > turn iscsitadm into being completely authorization driven? ;-) > > > No authorization is needed for iscsitadm, the cli sends the request to > the daemon and > the daemon verify the user credential. I don't think update to the man > page is needed. What daemon would that be? svc.configd is in charge of changing properties and enforcing authorizations for the repository. Without man page updates, how is the admin going to know that the user/role must have the Iscsi Target Management Rights Profile to successfully run iscsitadm? > > It would be nice to see the updated man page. > > > > > >> Issues: > >> -The CHAP secret will be put back after PSARC 2007/177 is putback. > >> The PSARC 2007/414 will > >> cover the putback of the CHAP secret at a later time, and no > >> additional case is needed. > >> > > > > I'm not sure how to read this. Is this accepting a case dependency > > on 2007/177? Or is it saying that a two phase project is being > > requested. Phase 1 without CHAP, phase 2 after 177 with CHAP. > > > We are requesting to make this a 2 phase project, and we will provide > all the documents to > address both phases. The 2nd phase will accept the 2007/177 dependency. Is the project complete in phase 1? Is the intent that this ARC case cover both phases? Why is a phased approach needed or desirable to the administrator? Gary.. From Tim.Szeto@Sun.COM Wed Aug 8 13:30:55 2007 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 l78KUtON027489 for ; Wed, 8 Aug 2007 13:30:55 -0700 (PDT) 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 l78KSSpd019360; Wed, 8 Aug 2007 14:28:28 -0600 (MDT) 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 <0JMH00C0F27M6300@brm-avmta-1.central.sun.com>; Wed, 08 Aug 2007 14:28:34 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMH0048E27LBF70@brm-avmta-1.central.sun.com>; Wed, 08 Aug 2007 14:28:33 -0600 (MDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l78KSXdw007356; Wed, 08 Aug 2007 20:28:33 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JMH00A011YQ9T00@mail-amer.sun.com> (original mail from Tim.Szeto@Sun.COM) ; Wed, 08 Aug 2007 14:28:33 -0600 (MDT) Received: from [129.150.33.64] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMH003BB27ILSP8@mail-amer.sun.com>; Wed, 08 Aug 2007 14:28:32 -0600 (MDT) Date: Wed, 08 Aug 2007 14:28:15 -0600 From: Tim Szeto Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <200708081759.l78Hx2mk009005@marduk.eng.sun.com> Sender: Tim.Szeto@Sun.COM To: Gary Winiger Cc: Chris.Liu@Sun.COM, Darren.Moffat@Sun.COM, Keith.Wesolowski@Sun.COM, Kenneth.Davis@Sun.COM, Mark.Carlson@Sun.COM, Nicolas.Williams@Sun.COM, PSARC-ext@Sun.COM, iscsi-tgt-iteam@Sun.COM, sommerfeld@Sun.COM Message-id: <46BA275F.7010601@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: <200708081759.l78Hx2mk009005@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 3674 Gary Winiger wrote: >> Gary Winiger wrote: >> >>>> Summary of the concerns and proposed solutions for the PSARC 2007/414: >>>> >>>> Concern: Does clear text CHAP secret provides enough security? >>>> > > It seems that this project is being factored to bypass this issue. > See the project teams response below. > Is the project complete without a CHAP secret? > No, we need to move all configuration data to SCF including CHAP secrets. > >>> I'm going to leave this one for now to get a feeling of others. >>> >>> >>> >>>> Concern: The iSCSI target manifest does not comply with SMF authorization. >>>> Proposal: >>>> -We will add action_authorization and value_authorization to the >>>> manifest to make >>>> it SMF authorization compliant. >>>> >>>> >>> Good. Is there an updated spec showing this? >>> >> I updated the scf_design doc with a section on "Iscsi Target RBAC >> authorization". >> > > At the code review level, I'm not sure > 2. Iscsitgt service manifest > will do what you want it to do. Please have the SMF folk code > review your service manifest. > Yes, this will require code review from the SMF folk. Since the original PSARC only address the conversion of configuration to SCF data, the issue of RBAC came up during this PSRAC exchange, I'm requesting to open a P3 CR to address the RBAC issue, this should not affect the security issue with the implementation of PSARC 2007/177, this will speed up the putback of the SCF converson. > >>> Some how, I've >>> missed the FMRI and man pages documenting it. Shouldn't this >>> turn iscsitadm into being completely authorization driven? ;-) >>> >>> >> No authorization is needed for iscsitadm, the cli sends the request to >> the daemon and >> the daemon verify the user credential. I don't think update to the man >> page is needed. >> > > What daemon would that be? The iscsitgtd daemon performs all scf operations and verify the data are correct, this is the prefer method to update the iscsi target configuration. > svc.configd is in charge of changing > properties and enforcing authorizations for the repository. > Without man page updates, how is the admin going to know > that the user/role must have the Iscsi Target Management Rights > Profile to successfully run iscsitadm? > We can add the RBAC authorization to the iscsitadm(1M) man pages for the RBAC authorization putback. > >>> It would be nice to see the updated man page. >>> >>> >>> >>>> Issues: >>>> -The CHAP secret will be put back after PSARC 2007/177 is putback. >>>> The PSARC 2007/414 will >>>> cover the putback of the CHAP secret at a later time, and no >>>> additional case is needed. >>>> >>>> >>> I'm not sure how to read this. Is this accepting a case dependency >>> on 2007/177? Or is it saying that a two phase project is being >>> requested. Phase 1 without CHAP, phase 2 after 177 with CHAP. >>> >>> >> We are requesting to make this a 2 phase project, and we will provide >> all the documents to >> address both phases. The 2nd phase will accept the 2007/177 dependency. >> > > Is the project complete in phase 1? No. > Is the intent that this > ARC case cover both phases? Yes, the reason for the 2 phases was because of the dependency on PSARC 2007/177. > Why is a phased approach needed or > desirable to the administrator? > It's probably not desirable, but without knowing when 2007/177 will be approve, that how we scheduled the project. -Tim > Gary.. > From gww@eng.sun.com Wed Aug 8 14:08:22 2007 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 l78L8Lhh028242 for ; Wed, 8 Aug 2007 14:08:22 -0700 (PDT) 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 l78L60Jc008130; Thu, 9 Aug 2007 05:06:01 +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 <0JMH00B053XZ2400@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Aug 2007 14:05:59 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMH0052Z3XXO170@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Aug 2007 14:05:57 -0700 (PDT) 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 l78L5rPA008178; Wed, 08 Aug 2007 14:05:53 -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 l78L9rPK009422; Wed, 08 Aug 2007 14:09:53 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l78L9rqV009421; Wed, 08 Aug 2007 14:09:53 -0700 (PDT) Date: Wed, 08 Aug 2007 14:09:53 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] To: gww@eng.sun.com, Tim.Szeto@Sun.COM Cc: Chris.Liu@Sun.COM, Darren.Moffat@Sun.COM, Keith.Wesolowski@Sun.COM, Kenneth.Davis@Sun.COM, Mark.Carlson@Sun.COM, Nicolas.Williams@Sun.COM, PSARC-ext@Sun.COM, iscsi-tgt-iteam@Sun.COM, sommerfeld@Sun.COM Message-id: <200708082109.l78L9rqV009421@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 4644 > Gary Winiger wrote: > >> Gary Winiger wrote: > >> > >>>> Summary of the concerns and proposed solutions for the PSARC 2007/414: > >>>> > >>>> Concern: Does clear text CHAP secret provides enough security? > >>>> > > > > It seems that this project is being factored to bypass this issue. > > See the project teams response below. > > Is the project complete without a CHAP secret? > > > No, we need to move all configuration data to SCF including CHAP secrets. Then what do you mean by factored to bypass this issue. > >>>> Concern: The iSCSI target manifest does not comply with SMF authorization. > >>>> Proposal: > >>>> -We will add action_authorization and value_authorization to the > >>>> manifest to make > >>>> it SMF authorization compliant. > > At the code review level, I'm not sure > > 2. Iscsitgt service manifest > > will do what you want it to do. Please have the SMF folk code > > review your service manifest. > > > Yes, this will require code review from the SMF folk. > > Since the original PSARC only address the conversion of configuration to > SCF data, the issue of RBAC > came up during this PSRAC exchange, I'm requesting to open a P3 CR to > address the RBAC issue, this > should not affect the security issue with the implementation of PSARC > 2007/177, this will speed up the > putback of the SCF converson. Boy and I confused. RBAC has been part of Greenline since day 0. The policy is articulated in a SAC policy that predates this case. IMO, no, adding RBAC is not a P3 bug. It is a TCR for this case. I'm close to derailing as I'm getting more and more confused by each exchange. I suggest you work with your case owner and get things straightened out. > >>> Some how, I've > >>> missed the FMRI and man pages documenting it. Shouldn't this > >>> turn iscsitadm into being completely authorization driven? ;-) > >>> > >>> > >> No authorization is needed for iscsitadm, the cli sends the request to > >> the daemon and > >> the daemon verify the user credential. I don't think update to the man > >> page is needed. > >> > > > > What daemon would that be? > The iscsitgtd daemon performs all scf operations and verify the data are > correct, this is the prefer method to > update the iscsi target configuration. Huh? The iscsitgtd program updates the repository? Why would that be? Still more confusion on my part. Certainly if iscsitgtd enforces authorizations and it will need to comply with the Solaris Audit policy. See SAC policies. > > svc.configd is in charge of changing > > properties and enforcing authorizations for the repository. > > Without man page updates, how is the admin going to know > > that the user/role must have the Iscsi Target Management Rights > > Profile to successfully run iscsitadm? > > > We can add the RBAC authorization to the iscsitadm(1M) man pages for the > RBAC authorization > putback. The point is to correctly document the administrative interface, not to just put up with annoying ARC members ;-) > >>>> Issues: > >>>> -The CHAP secret will be put back after PSARC 2007/177 is putback. > >>>> The PSARC 2007/414 will > >>>> cover the putback of the CHAP secret at a later time, and no > >>>> additional case is needed. > >>>> > >>>> > >>> I'm not sure how to read this. Is this accepting a case dependency > >>> on 2007/177? Or is it saying that a two phase project is being > >>> requested. Phase 1 without CHAP, phase 2 after 177 with CHAP. > >>> > >>> > >> We are requesting to make this a 2 phase project, and we will provide > >> all the documents to > >> address both phases. The 2nd phase will accept the 2007/177 dependency. > >> > > > > Is the project complete in phase 1? > No. > > Is the intent that this > > ARC case cover both phases? > Yes, the reason for the 2 phases was because of the dependency on PSARC > 2007/177. > > Why is a phased approach needed or > > desirable to the administrator? > > > It's probably not desirable, but without knowing when 2007/177 will be > approve, that how we > scheduled the project. Schedule is not an architectural consideration. 2007/177 has been approved. It is out for code review. If you have schedule issues, you need management to coordinate the projects. So I'd say from this interchange that this case has a dependency on 2007/177 and must deliver a full case. Please work with your case owner to come up with a spec for this case that clears up the issues raised. Gary.. From Mark.Carlson@sun.com Wed Aug 8 15:54:07 2007 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 l78Ms6vB001748 for ; Wed, 8 Aug 2007 15:54:06 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l78MpiXc005053; Wed, 8 Aug 2007 23:51:45 +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 <0JMH00K038U7QP00@brm-avmta-1.central.sun.com>; Wed, 08 Aug 2007 16:51:43 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JMH0047P8U6BFD0@brm-avmta-1.central.sun.com>; Wed, 08 Aug 2007 16:51:42 -0600 (MDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l78Mpg20029129; Wed, 08 Aug 2007 22:51:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JMH00L018BDMO00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM); Wed, 08 Aug 2007 16:51:42 -0600 (MDT) Received: from dhcp-usfo07-89-111.sfbay.sun.com ([129.144.89.111]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JMH003MP8U5LSR8@mail-amer.sun.com>; Wed, 08 Aug 2007 16:51:42 -0600 (MDT) Date: Wed, 08 Aug 2007 16:51:40 -0600 From: "Mark A. Carlson" Subject: Re: SCF changes for iSCSI Target [PSARC/2007/414 FastTrack timeout 07/31/2007] In-reply-to: <200708082109.l78L9rqV009421@marduk.eng.sun.com> Sender: Mark.Carlson@sun.com To: Gary Winiger Cc: Tim.Szeto@sun.com, Nicolas.Williams@sun.com, Darren.Moffat@sun.com, Kenneth.Davis@sun.com, sommerfeld@sun.com, PSARC-ext@sun.com, iscsi-tgt-iteam@sun.com, Keith.Wesolowski@sun.com, Chris.Liu@sun.com Message-id: <46BA48FC.6010805@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: <200708082109.l78L9rqV009421@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 322 I have marked the case "waiting need spec" -- mark Gary Winiger wrote: > ... > > Please work with your case owner to come up with a spec for this > case that clears up the issues raised. > > Gary.. > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > From Mark.Carlson@sun.com Mon Sep 10 15:53:36 2007 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 l8AMrZ9q008428 for ; Mon, 10 Sep 2007 15:53:35 -0700 (PDT) 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 l8AMogKQ012493 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 11 Sep 2007 06:50:44 +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 <0JO600K05CSJSP00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Sep 2007 15:50:43 -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 <0JO60089ACSIVCF0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Sep 2007 15:50:42 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8AMogG1016931 for ; Mon, 10 Sep 2007 22:50:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JO600G01C9Y6200@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Sep 2007 16:50:42 -0600 (MDT) Received: from MACsMAC.local ([129.150.35.59]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JO6003NSCSHLE6A@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 10 Sep 2007 16:50:42 -0600 (MDT) Date: Mon, 10 Sep 2007 16:50:37 -0600 From: "Mark A. Carlson" Subject: SCF changes for iSCSI Target PSARC/2007/414 FastTrack [restart] Sender: Mark.Carlson@sun.com To: psarc-ext@sun.com Cc: Tim Szeto , Kenneth Davis Message-id: <46E5CA3D.8060006@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.6 (Macintosh/20070728) Status: RO Content-Length: 446 I've restarted the timer on this fast-track case; it's now set to 09/14/2007. Updated materials have been placed in the case directory: -rw-r--r-- 1 ts143224 sacmail 17452 Sep 10 15:23 iscsitadm(1m) -rw-rw-r-- 1 markcarl sacmail 6459 Sep 10 15:23 scf_design -rw-r--r-- 1 ts143224 staff 5228 Sep 10 11:45 scf_schema -rw-r--r-- 1 ts143224 sacmail 5160 Sep 10 15:21 func_spec Please review and comment. Thanks, -- mark From gww@eng.sun.com Tue Sep 11 17:57:26 2007 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 l8C0vPUY010696 for ; Tue, 11 Sep 2007 17:57:26 -0700 (PDT) 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 l8C0sXJY001015 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Sep 2007 08:54: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 <0JO800F05D6YU500@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Sep 2007 18:54:34 -0600 (MDT) 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 <0JO800AQ7D6XIPE0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 11 Sep 2007 18:54:33 -0600 (MDT) 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 l8C0sWKj015312; Tue, 11 Sep 2007 17:54:32 -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 l8C0tkuI026041; Tue, 11 Sep 2007 17:55:46 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l8C0tkiM026040; Tue, 11 Sep 2007 17:55:46 -0700 (PDT) Date: Tue, 11 Sep 2007 17:55:46 -0700 (PDT) From: Gary Winiger Subject: Re: SCF changes for iSCSI Target PSARC/2007/414 FastTrack [restart] To: Mark.Carlson@sun.com, psarc-ext@sun.com Cc: Kenneth.Davis@sun.com, Tim.Szeto@sun.com Message-id: <200709120055.l8C0tkiM026040@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 6871 > I've restarted the timer on this fast-track case; it's now set to > 09/14/2007. Sigh. I'm getting quite frustrated with this review. Somehow when I believed the project team and case owner understood the issues, I thought I'd see that more clearly reflected in the updated materials. Maybe I'm misreading or just being too picky. I've certainly missed seeing how the CLI commands end up at svc.configd in the CLI callers context. Can we just get it right? Is that too much to ask? I thought I gave the project team all the things to say and write in the telecon. I don't see it reflected in the updated spec. Does the smf project team agree that this will all work as specified? Please oh please explain why http://opensolaris.org/os/community/arc/policies/SMF-policy/;jsessionid=3EC010F3467A31CCC9E5BD6C4C2FEF51 is so hard to understand. I want to make it clear. See below for the detailed context. > -rw-rw-r-- 1 markcarl sacmail 6459 Sep 10 15:23 scf_design > High Level: > -The CLI still uses the door interface to the daemon, the mgmt > interfaces are used to create incore database and then use the > mgmt_scf interfaces to create/modify/delete the SCF database. How does this work so that svc.configd enforces policy based on the caller of the CLI and audits these changes correctly? > Issue > ====== > The property CHAP SECRETS is converted to SCF after PSARC 2007/177 > is putback. Again, does this mean that this case is dependent on 177 and will not putback before it, or is this saying something else? Why is this an issue and not a case dependency? > 1. Iscsitgt service > > The following authorizations are added to the auth_attr(4) file: > > solaris.smf.action.iscsitgt:::Action ISCSITGT Service::help=SmfIscsitgtStates.html > solaris.smf.value.iscsitgt:::Change ISCSITGT Service Properties::help=SmfValueIscsitgt.html > solaris.smf.read.iscsitgt:::Read Protected ISCSITGT Properties::help=SmfReadIscsitgt.html Code review level. Missing from here is the manage authorization. Please oh please show md with anything of the form solaris.smf.action is part of the policy? > The following profile is added to the prof_attr(4) file: > > Iscsi Target Management:::iSCSI Target Management:help=RtIscsitgtMngmnt.html:auths=solaris.smf.manage.iscsitgt,solaris.smf.value.iscsitgt,solaris.smf.read.iscsitgt Does a single profile really make sense? Is it expected that there would be no separation of duties between admins who can create new targets, or delete targets or set passwords and those who can modify existing target values? Did the SMF team say that no modify_authorization was needed? Remember the whole point is that an admin with the appropriate Rights Profile can run the CLI. See above question of how the daemon works. > 2. Iscsitgt service manifest > > > value='solaris.smf.action.iscsitgt' /> ^^^^^^ Gosh doesn't the sfm policy say manage? And wouldn't this be in the general/framework property group? > value='solaris.smf.value.iscsitgt' /> > > value='solaris.smf.read.iscsitgt' /> > What does the smf project team have to say about this? Shouldn't value and read authorizations be part of the PG that they affect? > -rw-r--r-- 1 ts143224 sacmail 5160 Sep 10 15:21 func_spec > 1.3 Changes From the Previous Release > > This is a change from PSARC 2005/441. This will be a micro/ > patch release. The changes are moving persistent data stored > in files to the SMF repository. The persistent data are project > private and managed by the iSCSI Target daemon. How does this release binding align with > 2.4 Compatibility and Interoperability > > 2.4.7 Compatibility with Earlier and Future Releases > > There is no changes to the interface (iscsitadm(1M)). > > The persistent data will be converted from XML to > SCF upon this upgrade. After the upgrade, the persistent > data cannot revert back to the XML format. and the requirement that patches be able to be backed out? Does anyone actually care that this doesn't appear to be able to be backed out? Or upon upgrade do you keep all the old configuration files? What's the patchrm story? > iscsitgt.xml: > Add RBAC authorization for action_authorization and > value_authorization. Are there no modify_authorization's needed? > auth_attr: > Add authorization attributes: > solaris.smf.value.iscsitgt > solaris.smf.read.iscsitgt Missing here would seem to be solaris.smf.manage.iscsitgt > prof_attr: > Add iSCSI Target Management rights profile. See above. Perhaps more than one profile is desired. > iSCSI Target Daemon: > Add SCF functionality and RBAC authorization. What is this saying the daemon is doing with authorization? > 1.5 Related Projects > > 1.5.1 Dependencies on Other Sun Projects > > PSARC 2007/177 smf(5) enhancements for storage of > sensitive properties Is this saying that isn't an issue as seemed to be stated in smf_design? > 2.2 Interfaces > > The interface is Project Private and Evolving. This > interface is iscsitadm and iscsi target daemon. I'm not sure what is being stated here, is this saying the interface between the CLI and the daemon is PP and the CLI itself is Evolving? Or is it saying something else? > 2.7 Security > Issue: > RBAC authorization > > Solution: > We propose the following RBAC authorizations for managing > iSCSI Target properties (auth_attr(4)): Reitterating from above. Is there no need for a modify_authorization to be specified? Has this been prototyped and an admin with just the specified Rights Profile can effectively do things? N.B. That same admin should be able to do the very same things with svcadm and svccfg. If they can't I fear there's something not right. Did I miss how the CLI enables the service? Or is there some missing documentation to use svcadm enable? > We will add an iSCSI Target Management rights profile to > the iSCSI Target service (prof_attr(4)): > > ISCSI Target Management:::ISCSI Target Management:\ > auths=solaris.smf.value.iscsitgt,\ > solaris.smf.read.iscsitgt,\ > solaris.smf.action.iscsitgt;\ ^^^^^^ Don't you mean manage? Gary.. From Tim.Szeto@Sun.COM Wed Sep 12 10:20:52 2007 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 l8CHKp7H029029 for ; Wed, 12 Sep 2007 10:20:52 -0700 (PDT) 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 l8CHHxSe020445 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 13 Sep 2007 01:18:00 +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 <0JO900309MPXBX00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Sep 2007 11:17:57 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JO900GTJMPWW6C0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Sep 2007 11:17:56 -0600 (MDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8CHHutO018654 for ; Wed, 12 Sep 2007 17:17:56 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JO900701MDIIP00@mail-amer.sun.com> (original mail from Tim.Szeto@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Sep 2007 11:17:56 -0600 (MDT) Received: from [172.20.58.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JO9007XMMPWLHU5@mail-amer.sun.com>; Wed, 12 Sep 2007 11:17:56 -0600 (MDT) Date: Wed, 12 Sep 2007 11:15:45 -0600 From: tim szeto Subject: Re: SCF changes for iSCSI Target PSARC/2007/414 FastTrack [restart] In-reply-to: <200709120055.l8C0tkiM026040@marduk.eng.sun.com> Sender: Tim.Szeto@Sun.COM To: Gary Winiger Cc: Mark.Carlson@Sun.COM, psarc-ext@Sun.COM, Kenneth.Davis@Sun.COM, ChrisL Message-id: <46E81EC1.7060408@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: <200709120055.l8C0tkiM026040@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 8526 Gary Winiger wrote: >> I've restarted the timer on this fast-track case; it's now set to >> 09/14/2007. >> > > Sigh. I'm getting quite frustrated with this review. Somehow > when I believed the project team and case owner understood the > issues, I thought I'd see that more clearly reflected in the > updated materials. Maybe I'm misreading or just being too picky. > I've certainly missed seeing how the CLI commands end up > at svc.configd in the CLI callers context. > > > Can we just get it right? Is that too much to ask? I thought I > gave the project team all the things to say and write in the > telecon. I don't see it reflected in the updated spec. Does the > smf project team agree that this will all work as specified? > Please oh please explain why > http://opensolaris.org/os/community/arc/policies/SMF-policy/;jsessionid=3EC010F3467A31CCC9E5BD6C4C2FEF51 > is so hard to understand. I want to make it clear. See below > for the detailed context. > > > >> -rw-rw-r-- 1 markcarl sacmail 6459 Sep 10 15:23 scf_design >> > > >> High Level: >> > > >> -The CLI still uses the door interface to the daemon, the mgmt >> interfaces are used to create incore database and then use the >> mgmt_scf interfaces to create/modify/delete the SCF database. >> > > How does this work so that svc.configd enforces policy based > on the caller of the CLI and audits these changes correctly? > We will have the svc.configd authenticate the CLI user. > > >> Issue >> ====== >> The property CHAP SECRETS is converted to SCF after PSARC 2007/177 >> is putback. >> > > Again, does this mean that this case is dependent on 177 > and will not putback before it, or is this saying something > else? Why is this an issue and not a case dependency? > PSARC 2007/177 is a dependency, we will not putback until PSARC 2007/177 is putback. > >> 1. Iscsitgt service >> >> The following authorizations are added to the auth_attr(4) file: >> >> solaris.smf.action.iscsitgt:::Action ISCSITGT Service::help=SmfIscsitgtStates.html >> solaris.smf.value.iscsitgt:::Change ISCSITGT Service Properties::help=SmfValueIscsitgt.html >> solaris.smf.read.iscsitgt:::Read Protected ISCSITGT Properties::help=SmfReadIscsitgt.html >> > > Code review level. Missing from here is the manage authorization. > Please oh please show md with anything of the form solaris.smf.action > is part of the policy? > Yes, manage_authorization will be added. > > >> The following profile is added to the prof_attr(4) file: >> >> Iscsi Target Management:::iSCSI Target Management:help=RtIscsitgtMngmnt.html:auths=solaris.smf.manage.iscsitgt,solaris.smf.value.iscsitgt,solaris.smf.read.iscsitgt >> > > Does a single profile really make sense? Is it expected that > there would be no separation of duties between admins who can > create new targets, or delete targets or set passwords and > those who can modify existing target values? > A single profile is sufficient. But if deemed best to have an additional profile, we will add additional profiles. > Did the SMF team say that no modify_authorization was needed? > Remember the whole point is that an admin with the appropriate > Rights Profile can run the CLI. See above question of how > the daemon works. > The modify_authorization is needed for creation of new target. > >> 2. Iscsitgt service manifest >> >> >> > value='solaris.smf.action.iscsitgt' /> >> > ^^^^^^ > Gosh doesn't the sfm policy say manage? And wouldn't > this be in the general/framework property group? > Yes, it should be solaris.smf.manage.iscsitgt. > >> > value='solaris.smf.value.iscsitgt' /> >> >> > value='solaris.smf.read.iscsitgt' /> >> >> > > What does the smf project team have to say about this? > Shouldn't value and read authorizations be part of the PG > that they affect? > I consulted with the SMF team, the read_authorization and value_authorization properties are needed in the PG. >> -rw-r--r-- 1 ts143224 sacmail 5160 Sep 10 15:21 func_spec >> > > >> 1.3 Changes From the Previous Release >> >> This is a change from PSARC 2005/441. This will be a micro/ >> patch release. The changes are moving persistent data stored >> in files to the SMF repository. The persistent data are project >> private and managed by the iSCSI Target daemon. >> > > How does this release binding align with > > >> 2.4 Compatibility and Interoperability >> >> 2.4.7 Compatibility with Earlier and Future Releases >> >> There is no changes to the interface (iscsitadm(1M)). >> >> The persistent data will be converted from XML to >> SCF upon this upgrade. After the upgrade, the persistent >> data cannot revert back to the XML format. >> > > and the requirement that patches be able to be backed out? > When the patch is backed out, the old configuration will be restore. > Does anyone actually care that this doesn't appear to be > able to be backed out? Or upon upgrade do you keep all the > old configuration files? We backup the old configuration files. > What's the patchrm story? > We will restore the old configuration file with patchrm. > >> iscsitgt.xml: >> Add RBAC authorization for action_authorization and >> value_authorization. >> > > Are there no modify_authorization's needed? > modify_authorization is needed. > >> auth_attr: >> Add authorization attributes: >> solaris.smf.value.iscsitgt >> solaris.smf.read.iscsitgt >> > > Missing here would seem to be solaris.smf.manage.iscsitgt > solaris.smf.manage.iscsitgt is needed. > >> prof_attr: >> Add iSCSI Target Management rights profile. >> > > See above. Perhaps more than one profile is desired. > See response above. > >> iSCSI Target Daemon: >> Add SCF functionality and RBAC authorization. >> > > What is this saying the daemon is doing with authorization? > See above on how we do this architecturally. > >> 1.5 Related Projects >> >> 1.5.1 Dependencies on Other Sun Projects >> >> PSARC 2007/177 smf(5) enhancements for storage of >> sensitive properties >> > > Is this saying that isn't an issue as seemed to be > stated in smf_design? > PSARC 2007/177 is a dependency > >> 2.2 Interfaces >> >> The interface is Project Private and Evolving. This >> interface is iscsitadm and iscsi target daemon. >> > > I'm not sure what is being stated here, is this saying > the interface between the CLI and the daemon is PP The interface between the daemon and CLI is PP. > and > the CLI itself is Evolving? Or is it saying something > else? > We are not changing the interface classification of the CLI. > >> 2.7 Security >> > > >> Issue: >> RBAC authorization >> >> Solution: >> We propose the following RBAC authorizations for managing >> iSCSI Target properties (auth_attr(4)): >> > > Reitterating from above. Is there no need for a > modify_authorization to be specified? > modify_authorization is required > Has this been prototyped and an admin with just the > specified Rights Profile can effectively do things? > N.B. That same admin should be able to do the very same things > with svcadm and svccfg. If they can't I fear there's something > not right. > We agree this architectural approach. > Did I miss how the CLI enables the service? > Or is there some > missing documentation to use svcadm enable? > > >> We will add an iSCSI Target Management rights profile to >> the iSCSI Target service (prof_attr(4)): >> >> ISCSI Target Management:::ISCSI Target Management:\ >> auths=solaris.smf.value.iscsitgt,\ >> solaris.smf.read.iscsitgt,\ >> solaris.smf.action.iscsitgt;\ >> > ^^^^^^ > Don't you mean manage? > Yes. -Tim > Gary.. > From Tim.Szeto@sun.com Wed Sep 12 13:56:30 2007 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 l8CKuUXo006094 for ; Wed, 12 Sep 2007 13:56:30 -0700 (PDT) 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 l8CKrdCY027470 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 12 Sep 2007 13:53:39 -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 <0JO900603WPEJE00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Sep 2007 13:53:38 -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 <0JO9004Z8WPED600@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Sep 2007 13:53:38 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8CKrcAH015518 for ; Wed, 12 Sep 2007 20:53:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JO900M01WKZQ000@mail-amer.sun.com> (original mail from Tim.Szeto@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 12 Sep 2007 14:53:38 -0600 (MDT) Received: from [172.20.58.124] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JO90048SWPDR4VF@mail-amer.sun.com>; Wed, 12 Sep 2007 14:53:37 -0600 (MDT) Date: Wed, 12 Sep 2007 14:51:27 -0600 From: tim szeto Subject: Re: SCF changes for iSCSI Target PSARC/2007/414 FastTrack [restart] In-reply-to: <46E81EC1.7060408@sun.com> Sender: Tim.Szeto@sun.com To: Gary Winiger Cc: tim szeto , Mark.Carlson@sun.com, PSARC-ext@sun.com, Kenneth.Davis@sun.com, ChrisL Message-id: <46E8514F.5060702@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: <200709120055.l8C0tkiM026040@marduk.eng.sun.com> <46E81EC1.7060408@sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 9361 This is a correction to my previous response. See CORRECTION; in email tim szeto wrote: > > > Gary Winiger wrote: >>> I've restarted the timer on this fast-track case; it's now set to >>> 09/14/2007. >>> >> >> Sigh. I'm getting quite frustrated with this review. Somehow >> when I believed the project team and case owner understood the >> issues, I thought I'd see that more clearly reflected in the >> updated materials. Maybe I'm misreading or just being too picky. >> I've certainly missed seeing how the CLI commands end up >> at svc.configd in the CLI callers context. >> >> >> Can we just get it right? Is that too much to ask? I thought I >> gave the project team all the things to say and write in the >> telecon. I don't see it reflected in the updated spec. Does the >> smf project team agree that this will all work as specified? >> Please oh please explain why >> http://opensolaris.org/os/community/arc/policies/SMF-policy/;jsessionid=3EC010F3467A31CCC9E5BD6C4C2FEF51 >> >> is so hard to understand. I want to make it clear. See below >> for the detailed context. >> >> >> >>> -rw-rw-r-- 1 markcarl sacmail 6459 Sep 10 15:23 scf_design >>> >> >> >>> High Level: >>> >> >> >>> -The CLI still uses the door interface to the daemon, the mgmt >>> interfaces are used to create incore database and then use the >>> mgmt_scf interfaces to create/modify/delete the SCF database. >>> >> >> How does this work so that svc.configd enforces policy based >> on the caller of the CLI and audits these changes correctly? >> > We will have the svc.configd authenticate the CLI user. >> >> >>> Issue >>> ====== >>> The property CHAP SECRETS is converted to SCF after PSARC 2007/177 >>> is putback. >>> >> >> Again, does this mean that this case is dependent on 177 >> and will not putback before it, or is this saying something >> else? Why is this an issue and not a case dependency? >> > PSARC 2007/177 is a dependency, we will not putback until PSARC > 2007/177 is putback. >> >>> 1. Iscsitgt service >>> >>> The following authorizations are added to the auth_attr(4) file: >>> >>> solaris.smf.action.iscsitgt:::Action ISCSITGT >>> Service::help=SmfIscsitgtStates.html >>> solaris.smf.value.iscsitgt:::Change ISCSITGT Service >>> Properties::help=SmfValueIscsitgt.html >>> solaris.smf.read.iscsitgt:::Read Protected ISCSITGT >>> Properties::help=SmfReadIscsitgt.html >>> >> >> Code review level. Missing from here is the manage authorization. >> Please oh please show md with anything of the form >> solaris.smf.action >> is part of the policy? >> > Yes, manage_authorization will be added. CORRECTION: The value of 'solaris.smf.action.iscsitgt' will be changed to 'solaris.smf.manage.iscsitgt' >> >> >>> The following profile is added to the prof_attr(4) file: >>> >>> Iscsi Target Management:::iSCSI Target >>> Management:help=RtIscsitgtMngmnt.html:auths=solaris.smf.manage.iscsitgt,solaris.smf.value.iscsitgt,solaris.smf.read.iscsitgt >>> >>> >> >> Does a single profile really make sense? Is it expected that >> there would be no separation of duties between admins who can >> create new targets, or delete targets or set passwords and >> those who can modify existing target values? >> > A single profile is sufficient. But if deemed best to have an > additional profile, we will add additional > profiles. >> Did the SMF team say that no modify_authorization was needed? >> Remember the whole point is that an admin with the appropriate >> Rights Profile can run the CLI. See above question of how >> the daemon works. >> > The modify_authorization is needed for creation of new target. >> >>> 2. Iscsitgt service manifest >>> >>> >>> >> value='solaris.smf.action.iscsitgt' /> >>> >> ^^^^^^ >> Gosh doesn't the sfm policy say manage? And wouldn't >> this be in the general/framework property group? >> > Yes, it should be solaris.smf.manage.iscsitgt. >> >>> >> value='solaris.smf.value.iscsitgt' /> >>> >>> >> value='solaris.smf.read.iscsitgt' /> >>> >>> >> >> What does the smf project team have to say about this? >> Shouldn't value and read authorizations be part of the PG >> that they affect? >> > I consulted with the SMF team, the read_authorization and > value_authorization > properties are needed in the PG. >>> -rw-r--r-- 1 ts143224 sacmail 5160 Sep 10 15:21 func_spec >>> >> >> >>> 1.3 Changes From the Previous Release >>> >>> This is a change from PSARC 2005/441. This will be a micro/ >>> patch release. The changes are moving persistent data stored >>> in files to the SMF repository. The persistent data are project >>> private and managed by the iSCSI Target daemon. >>> >> >> How does this release binding align with >> >>> 2.4 Compatibility and Interoperability >>> >>> 2.4.7 Compatibility with Earlier and Future Releases >>> >>> There is no changes to the interface (iscsitadm(1M)). >>> >>> The persistent data will be converted from XML to >>> SCF upon this upgrade. After the upgrade, the persistent >>> data cannot revert back to the XML format. >>> >> >> and the requirement that patches be able to be backed out? >> > When the patch is backed out, the old configuration will be restore. >> Does anyone actually care that this doesn't appear to be >> able to be backed out? Or upon upgrade do you keep all the >> old configuration files? > We backup the old configuration files. >> What's the patchrm story? >> > We will restore the old configuration file with patchrm. >> >>> iscsitgt.xml: >>> Add RBAC authorization for action_authorization and >>> value_authorization. >>> >> >> Are there no modify_authorization's needed? >> > modify_authorization is needed. >> >>> auth_attr: >>> Add authorization attributes: >>> solaris.smf.value.iscsitgt >>> solaris.smf.read.iscsitgt >>> >> >> Missing here would seem to be solaris.smf.manage.iscsitgt >> > solaris.smf.manage.iscsitgt is needed. >> >>> prof_attr: >>> Add iSCSI Target Management rights profile. >>> >> >> See above. Perhaps more than one profile is desired. >> > See response above. >> >>> iSCSI Target Daemon: >>> Add SCF functionality and RBAC authorization. >>> >> >> What is this saying the daemon is doing with authorization? >> > See above on how we do this architecturally. >> >>> 1.5 Related Projects >>> >>> 1.5.1 Dependencies on Other Sun Projects >>> >>> PSARC 2007/177 smf(5) enhancements for storage of >>> sensitive properties >>> >> >> Is this saying that isn't an issue as seemed to be >> stated in smf_design? >> > PSARC 2007/177 is a dependency >> >>> 2.2 Interfaces >>> >>> The interface is Project Private and Evolving. This >>> interface is iscsitadm and iscsi target daemon. >>> >> >> I'm not sure what is being stated here, is this saying >> the interface between the CLI and the daemon is PP > The interface between the daemon and CLI is PP. >> and >> the CLI itself is Evolving? Or is it saying something >> else? >> > We are not changing the interface classification of the CLI. >> >>> 2.7 Security >>> >> >> >>> Issue: >>> RBAC authorization >>> >>> Solution: >>> We propose the following RBAC authorizations for managing >>> iSCSI Target properties (auth_attr(4)): >>> >> >> Reitterating from above. Is there no need for a >> modify_authorization to be specified? >> > modify_authorization is required >> Has this been prototyped and an admin with just the >> specified Rights Profile can effectively do things? >> N.B. That same admin should be able to do the very same things >> with svcadm and svccfg. If they can't I fear there's something >> not right. >> > We agree this architectural approach. >> Did I miss how the CLI enables the service? Or is there some >> missing documentation to use svcadm enable? >> >> >>> We will add an iSCSI Target Management rights profile to >>> the iSCSI Target service (prof_attr(4)): >>> >>> ISCSI Target Management:::ISCSI Target Management:\ >>> auths=solaris.smf.value.iscsitgt,\ >>> solaris.smf.read.iscsitgt,\ >>> solaris.smf.action.iscsitgt;\ >>> >> ^^^^^^ >> Don't you mean manage? >> > Yes. > > -Tim > >> Gary.. >> > From sommerfeld@sun.com Wed Sep 12 16:09:01 2007 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 l8CN91Pr012061 for ; Wed, 12 Sep 2007 16:09:01 -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 l8CN69Ce025417; Wed, 12 Sep 2007 16:06:10 -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 <0JOA00M1V2U9UU00@brm-avmta-1.central.sun.com>; Wed, 12 Sep 2007 17:06:09 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOA00J5Q2U8PC20@brm-avmta-1.central.sun.com>; Wed, 12 Sep 2007 17:06:08 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l8CN67Fo008996; Wed, 12 Sep 2007 19:06:07 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l8CN67kp016278; Wed, 12 Sep 2007 19:06:07 -0400 (EDT) Date: Wed, 12 Sep 2007 19:06:06 -0400 From: Bill Sommerfeld Subject: Re: SCF changes for iSCSI Target PSARC/2007/414 FastTrack [restart] In-reply-to: <46E5CA3D.8060006@sun.com> To: "Mark A. Carlson" Cc: psarc-ext@sun.com, Kenneth Davis , Tim Szeto Message-id: <1189638366.14897.177.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.10.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <46E5CA3D.8060006@sun.com> Status: RO Content-Length: 1503 in scf_schema, we find: > chap_secrets > target_chap SCF_TYPE_USTRING > initiator_chap SCF_TYPE_USTRING > radius_chap SCF_TYPE_USTRING > value_authorization SCF_TYPE_ASTRING > read_authorization SCF_TYPE_ASTRING vs. > The chap_secret pgroup contains chap secrets for target, initiators > and radius server. vs. (in a later example): chap_secret iscsitgt fasfre4j4j49h33232fhffaieiei initiator_s6r fasfre4j4j49h33232fhffaieiei radius-secret 94jnfjsleoo445 value_authorization solaris.smf.value.iscsitgt read_authorization solaris.smf.read.iscsitgt Is it "chap_secret" or "chap_secrets" ? It appears that rather than the property names being literally "target_chap" and "initiator_chap", the properties are actually given the name of the initiator and target property groups, and there could be many such attributes in the property group? What prevents the creation of a target or initiator named "read_authorization"? what, if anything prevents a name collision between an initiator and a target? also, what measures are taken to conform to the requirements of 2007/177 in terms of additional protection or obfuscation of properties? > The chap secret is default to NULL. But there are multiple chap secrets created with dynamic names? - Bill From Tim.Szeto@sun.com Wed Sep 12 17:05:56 2007 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 l8D05uPE014080 for ; Wed, 12 Sep 2007 17:05:56 -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 l8D034nT018448; Wed, 12 Sep 2007 17:03:05 -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 <0JOA0030X5H36Z00@brm-avmta-1.central.sun.com>; Wed, 12 Sep 2007 18:03:03 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JOA00JRO5H2P040@brm-avmta-1.central.sun.com>; Wed, 12 Sep 2007 18:03:02 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8D032sM014301; Thu, 13 Sep 2007 00:03:02 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JOA00D015GU6C00@mail-amer.sun.com> (original mail from Tim.Szeto@Sun.COM) ; Wed, 12 Sep 2007 18:03:02 -0600 (MDT) Received: from [129.150.33.211] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JOA00MOU5H12JUE@mail-amer.sun.com>; Wed, 12 Sep 2007 18:03:02 -0600 (MDT) Date: Wed, 12 Sep 2007 18:02:23 -0600 From: Tim Szeto Subject: Re: SCF changes for iSCSI Target PSARC/2007/414 FastTrack [restart] In-reply-to: <1189638366.14897.177.camel@thunk> Sender: Tim.Szeto@sun.com To: Bill Sommerfeld Cc: "Mark A. Carlson" , PSARC-ext@sun.com, Kenneth Davis , Chris Liu , Tim.Szeto@sun.com Message-id: <46E87E0F.1050900@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: <46E5CA3D.8060006@sun.com> <1189638366.14897.177.camel@thunk> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) Status: RO Content-Length: 3111 Bill, Bill Sommerfeld wrote: > in scf_schema, we find: > > >> chap_secrets >> target_chap SCF_TYPE_USTRING >> initiator_chap SCF_TYPE_USTRING >> radius_chap SCF_TYPE_USTRING >> value_authorization SCF_TYPE_ASTRING >> read_authorization SCF_TYPE_ASTRING >> > > vs. > > >> The chap_secret pgroup contains chap secrets for target, initiators >> and radius server. >> > > vs. (in a later example): > > chap_secret > iscsitgt fasfre4j4j49h33232fhffaieiei > initiator_s6r fasfre4j4j49h33232fhffaieiei > radius-secret 94jnfjsleoo445 > value_authorization solaris.smf.value.iscsitgt > read_authorization solaris.smf.read.iscsitgt > > > Is it "chap_secret" or "chap_secrets" ? > There are many chap secrets, here are the chap secrets: -chap secret for the iscsi target -1 chap secret per iscsi initiator, we have 1 or more iscsi initiator -1 chap secret for the radius server For the chap_secret PG, we will have a read_authorization property added to the chap_secrets PG. > It appears that rather than the property names being literally > "target_chap" and "initiator_chap", the properties are actually given > the name of the initiator and target property groups, and there could be > many such attributes in the property group? > Yes. The property_name of an initiator_chap will be identified by the initiator_name, and the initiator_name is unique for each initiator. > What prevents the creation of a target or initiator named > "read_authorization"? > The read_authorization property is created only for the chap_secrets PG. > what, if anything prevents a name collision between an initiator and a > target? > When a new target is created, the iscsi target name creation is guarantee to be unique. The initiator name at the iSCSI target is a local name defined by the administrator, the initiator name is verified not already used. > also, what measures are taken to conform to the requirements of 2007/177 > in terms of additional protection or obfuscation of properties? > We are proposing the use of base64 encoding to obscure the the chap secrets. I will update the scf_schema to reflect the obfuscation of the secrets using base64 encoding. > >> The chap secret is default to NULL. >> > > I do not mean NULL, I mean the chap property_name is not define in the chap_secrets PG. When chap is not define, this means CHAP authentication is not required to authenticate the iscsi initiator and target. > But there are multiple chap secrets created with dynamic names? > Let me clarify, the chap secret for the target, initiators and radius server are created dynamically, when the administrator creates the chap secret, the PG names of the target, initiators and the radius server are known, we use these name for the chap property_name in the chap_secrets PG. thanks, Tim > - Bill > > > > > > From Mark.Carlson@Sun.COM Mon Sep 17 14:56:29 2007 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 l8HLuSvC004191 for ; Mon, 17 Sep 2007 14:56:29 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l8HLrW3c001299 for ; Tue, 18 Sep 2007 05:53:33 +0800 (SGT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8HLrW3F019202 for ; Mon, 17 Sep 2007 21:53:32 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 <0JOJ00F0186UV800@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 15:53:32 -0600 (MDT) Received: from MACsMAC.local ([129.150.35.193]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOJ007KP8T2KI90@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 17 Sep 2007 15:53:26 -0600 (MDT) Date: Mon, 17 Sep 2007 15:53:25 -0600 From: "Mark A. Carlson" Subject: SCF changes for iSCSI Target PSARC/2007/414 FastTrack [timeout] In-reply-to: <46E5CA3D.8060006@sun.com> Sender: Mark.Carlson@Sun.COM To: psarc-ext@Sun.COM Cc: Tim Szeto , Kenneth Davis Message-id: <46EEF755.6090705@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <46E5CA3D.8060006@sun.com> User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) Status: RO Content-Length: 101 This case, having reached both consensus and it's timeout, has been marked closed approved. -- mark