From sacadmin Mon Jul 9 11:47:51 2007 Return-path: Received: from fe-sfbay-10.sun.com ([192.18.34.120]) by sfbay2-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JKX00F9UB2Q6OD0@sfbay2-mail1.sfbay.sun.com> for plocher@sfbay2-mail1.sfbay.Sun.COM; Mon, 09 Jul 2007 10:54:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JKX00101AWN6O00@fe-sfbay-10.sun.com> for plocher@sfbay2-mail1.sfbay.Sun.COM (ORCPT plocher@sfbay2-mail1.sfbay.Sun.COM) ; Mon, 09 Jul 2007 10:54:26 -0700 (PDT) Received: from phys-sfbay2-2.sfbay.sun.com ([129.145.47.19]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JKX003VOB2QNZ00@fe-sfbay-10.sun.com> for plocher@sfbay2-mail1.sfbay.Sun.COM (ORCPT plocher@sfbay2-mail1.sfbay.Sun.COM) ; Mon, 09 Jul 2007 10:54:26 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by sfbay2-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JKX00F9PB2Q6OD0@sfbay2-mail1.sfbay.sun.com> for plocher@sfbay2-mail1.sfbay.Sun.COM; Mon, 09 Jul 2007 10:54:26 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l69HsQSM012120; Mon, 09 Jul 2007 10:54:26 -0700 (PDT) Received: from spidey.central.sun.com (spidey.Central.Sun.COM [172.20.25.27]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l69HuJuQ001434; Mon, 09 Jul 2007 10:56:20 -0700 (PDT) Received: from spidey.central.sun.com (localhost [127.0.0.1]) by spidey.central.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l69HreMw011121; Mon, 09 Jul 2007 11:53:40 -0600 (MDT) Received: (from timh@localhost) by spidey.central.sun.com (8.14.1+Sun/8.14.1/Submit) id l69Hrc99011117; Mon, 09 Jul 2007 11:53:38 -0600 (MDT) Date: Mon, 09 Jul 2007 11:53:38 -0600 (MDT) From: Tim Haley - Sun Microsystem Subject: Modified Access Checks for CIFS [PSARC/2007/403 FastTrack timeout 07/16/2007] To: PSARC-ext@sun.com Cc: cifs-vfs-team@sun.com Message-id: <200707091753.l69Hrc99011117@spidey.central.sun.com> X-Envelope-from: John.Plocher@Sun.COM X-Envelope-to: psarc-record@sac.sfbay.sun.com MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Original-recipient: rfc822;plocher@sfbay2-mail1.sfbay.Sun.COM I am sponsoring this fast-track for Rich Brown. Requested binding is MINOR. Time-out is 16 July 2007. ------ Template Version: @(#)sac_nextcase 1.63 06/14/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Modified Access Checks for CIFS 1.2. Name of Document Author/Supplier: Author: Rich Brown 1.3 Date of This Document: 09 July, 2007 4. Technical Description CONTEXT This fast-track was spun off of the CIFS Service (PSARC 2006/715) case along with: PSARC 2007/218 caller_context_t in all VOPs PSARC 2007/227 VFS Feature Registration and ACL on Create PSARC 2007/244 ZFS case-insensitive support PSARC 2007/268 Support for CIFS share reservations PSARC 2007/315 Extensible Attribute Interfaces Although each of these changes are part of the bigger picture, they have been broken down into smaller pieces so each gets the attention it deserves. Several of these CIFS-related fast-tracks will describe changes to the signatures of vnode operations (VOPs) or the data structures they use. In some cases, these fast-tracks will describe multiple changes to the same VOPs. The project team intends to put all of these changes into ON in a single putback. NOTE: The VFSDEF_VERSION number in sys/vfs.h will be bumped from 3 to 4 in order to prevent unbundled file system kernel modules with the old signatures from loading. Once the unbundled file system modules are updated with the new signatures and recompiled, they will also pick up the new VFSDEF_VERSION number and be allowed to load. SUMMARY This case proposes the following changes to several vnode operations in general and to ZFS specifically to support the CIFS Server project (PSARC 2006/715). - Add V_APPEND as a value for the existing 'flags' field of VOP_ACCESS() to check for ACE-enforced append-only access to a vnode (file). - Add V_ACE_MASK as a value for the existing 'flags' field of VOP_ACCESS() which informs the implementation to treat the 'mode' parameter as a 32 bit ACE-style access mask. This is required to support the CIFS Service. - Add ATTR_NOACLCHECK as a value the existing flags field of the vnode operations that retrieve/modify attributes and ACLs. This prevents ACL checks from being performed when the caller has already been granted the permission to perform the operation on the vnode. This is required to support the CIFS Service. - Add a new value to the VFS Feature Registration facility (see PSARC 2007/227): VFSFT_ACEMASKONACCESS. File systems that support V_ACE_MASK and ATTR_NOACLCHECK will register VFSFT_ACEMASKONACCESS in their file system specific mount routines. This is necessary to protect legacy file systems that don't support the V_ACE_MASK and ATTR_NOACLCHECK features. This case requests MINOR binding. APPEND-ONLY ACCESS CHECKS In order to support file systems that implement the APPENDONLY attribute, a kernel method is required to check for ACE-enforced append-only access to a vnode. VOP_ACCESS() is the kernel interfaces used to check for read, write, and execute permission. This proposal adds V_APPEND to the existing 'flags' field of VOP_ACCESS() to explicitly check for append-only access. Legacy file systems that don't support append-only files can safely ignore this flag since VWRITE is required to be set in the 'mode' field for append-only access. ACE-STYLE ACCESS CHECKS The CIFS server performs access checks in terms of a 32 bit ACE-style access mask. This access mask has exactly the same format as the 32 bit "a_access_mask" member of the ace_t structure (defined in sys/acl.h) which is used by NFSv4 and ZFS. Note that the ACE-style access mask contains a richer set of access checks (e.g. read/write ACL, read/write attributes, list directory, delete child, etc.) which are not easily mapped into the simple VREAD/VWRITE/VEXEC mask that VOP_ACCESS() uses today. When a CIFS client attempts to open a file with a requested access mask, the server is responsible for verifying that the client has the appropriate permissions to access the file before it is opened. Once the file is open, the CIFS server retains an "access granted mask" which it uses to verify access for non-naming operations (e.g. read, write, getattr, setattr, etc.) on behalf of the client. This is different than the current Solaris model. In the Solaris model, VOP_ACCESS() is used to verify that the caller has permission to access the file based on three flags: VREAD (read permission), VWRITE (write permission), and VEXEC (execute permission). Once access has been verified (via VOP_ACCESS()) then the caller is free to perform any operations without further access checks with the exception of the following operations on file systems that support ACE-style ACLs (e.g., ZFS): VOP_GETATTR() /* Retrieve file attributes */ VOP_SETATTR() /* Set file attributes */ VOP_GETSECATTR() /* Retrieve security attributes (ACL) */ VOP_SETSECATTR() /* Set security attributes (ACL) */ For file systems that support ACE-style ACLs, such as ZFS, there is a check in each of these operations for ACE_READ_ATTRIBUTES, ACE_WRITE_ATTRIBUTES, ACE_READ_ACL, and ACE_WRITE_ACL. Since CIFS is the only service that requires an access check before each operation, the CIFS project team has agreed that the CIFS server will perform its own checks on behalf of its clients. This relieves the Solaris File System Infrastructure of this additional security burden. Providing an interface to verify access for a given access mask is accomplished by modifying VOP_ACCESS/fop_access to accept a 32 bit (ACE-style) access mask and providing a new flag, V_ACE_MASK, that requests that behavior. The current signature for VOP_ACCESS/fop_access is: int fop_access( vnode_t *vp, int mode, int flags, cred_t *cr, caller_context_t *ct) Fortunately, the existing signature lends itself to this solution. When the caller passes in the 32 bit ACE-style access mask as the 'mode' parameter, the caller will also pass the new V_ACE_MASK flag in the 'flags' field. This new behavior allows all the ACE checks to be made in VOP_ACCESS(). Note that the following attribute-related permissions are also checked (which is significant for the next section, ACL OVERRIDE): ACE_READ_ATTRIBUTES /* VOP_GETATTR() */ ACE_WRITE_ATTRIBUTES /* VOP_SETATTR() */ ACE_READ_ACL /* VOP_GETSECATTR() */ ACE_WRITE_ACL /* VOP_SETSECATTR() */ If V_ACE_MASK is set and the user corresponding to 'cr' (pointer to user's cred structure) has the permissions matching the 32-bit ACE-style access mask, then VOP_ACCESS/fop_access returns 0. Otherwise, it returns EACCESS. If the file system does NOT support V_ACE_MASK and this behavior is requested, the VOP_ACCESS() call will fail with EINVAL. (See "REGISTERING VFSFT_ACEMASKONACCESS" for further details.) ACL OVERRIDE There is still the matter of the attribute related operations currently performing explicit ACL checks on each invocation. The requirement is that once the CIFS server verifies its access mask via VOP_ACCESS(), then no further access checks on operations are to be performed. The problem that the CIFS server could encounter is that VOP_ACCESS() grants permissions to read/write attributes and/or ACLs (see previous section, ACCESS VERIFICATION) but the ACL is changed to disallow the operation that was previously granted. The solution that the CIFS and ZFS file system teams have agreed to is that the vnode operations that retrieve/modify file attributes and ACLs will pass a new flag, ATTR_NOACLCHECK, to the following operations: VOP_GETATTR(), VOP_SETATTR(), VOP_GETSECATTR(), and VOP_SETSECATTR(). When this flag is set, the corresponding file system operations will skip the ACL checks. Recall that the permissions to perform these operations would have already been granted to the CIFS server in the VOP_ACCESS() check. The ATTR_NOACLCHECK flag will be added to sys/vnode.h along with the other flags passed to these routines. The definition of the new flag is: #define ATTR_NOACLCHECK 0x20 /* Skip ACL checks */ Note that ATTR_NOACLCHECK only applies to file systems that also support V_ACE_MASK since that flavor of the VOP_ACCESS() call checks the permissions on the retrieval and modification of attributes and ACLs. If the file system does NOT support ATTR_NOACLCHECK and this behavior is requested, the VOP_ACCESS() call will fail with EINVAL. (See "REGISTERING VFSFT_ACEMASKONACCESS" for further details.) REGISTERING VFSFT_ACEMASKONACCESS Since not all file systems will be required to implement the V_ACE_MASK and ATTR_NOACLCHECK behavior, consumers need a way to query the file system to determine if this behavior is supported. This case introduces the VFSFT_ACEMASKONACCESS feature which can be registered on a vfs using the VFS Feature Registration facility (PSARC 2007/227). If a file system supports both (a) the V_ACE_MASK flag on VOP_ACCESS() and (b) ATTR_NOACLCHECK on the vnode operations that retrieve and modify attributes and ACLs, then the file system registers the VFSFT_ACEMASKONACCESS VFS Feature in its mount routine. The definition of VFSFT_ACEMASKONACCESS will be added to sys/vfs.h: #define VFSFT_ACEMASKONACCESS 0x100000020 /* Can use ACEMASK for access */ V_ACE_MASK can only be passed to VOP_ACCESS()/fop_access() on file systems that have registered the VFSFT_ACEMASKONACCESS feature. Otherwise, fop_access() will return EINVAL to the caller. ATTR_NOACLCHECK can only be passed (via VOP_GETATTR(), VOP_SETATTR(), VOP_GETSECATTR(), and VOP_SETSECATTR()) on file systems that have registered the VFSFT_ACEMASKONACCESS feature. Otherwise, the corresponding fop_*() routine will return EINVAL to the caller. SOLARIS FILE SYSTEM SUPPORT Since ZFS is the only Solaris file system that supports ACE-style ACLs, it will be the only file system to set the VFSFT_ACEMASKONACCESS VFS Feature and make use of ATTR_NOACLCHECK. EXPORTED INTERFACE TABLE |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== |Consolidation |This | VFSFT_ACEMASKONACCESS |Private |Document | Registerable vfs | | | feature | | | ATTR_NOACLCHECK | | | New flag for VOPs | | | that modify/retrieve | | | attributes and ACLs | | | V_ACE_MASK | | | New VOP_ACCESS() flag | | | to accept an ACE-style | | | access mask. | | | V_APPEND | | | New VOP_ACCESS() flag | | | to check for ACE- | | | enforced append-only | | | access | | | 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 don.cragun@sun.com Tue Jul 10 08:36:21 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 l6AFaLs0007033 for ; Tue, 10 Jul 2007 08:36:21 -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 l6AFYLdm029260; Tue, 10 Jul 2007 16:34:25 +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 <0JKY00001Z9CX400@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 08:34:24 -0700 (PDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKY000CKZ9BUC00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 10 Jul 2007 08:34:23 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with SMTP id l6AFYGwV002796; Tue, 10 Jul 2007 08:34:16 -0700 (PDT) Date: Tue, 10 Jul 2007 08:34:16 -0700 (PDT) From: Don Cragun Subject: Re: Modified Access Checks for CIFS [PSARC/2007/403 FastTrack timeout 07/16/2007] To: PSARC-ext@sun.com, timh@spidey.central.sun.com Cc: cifs-vfs-team@sun.com Reply-to: Don Cragun Message-id: <200707101534.l6AFYGwV002796@spartan.SFBay.Sun.COM> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: r6EwCa+XdU80se3/Fe0HfA== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1087 >Date: Mon, 09 Jul 2007 11:53:38 -0600 (MDT) >From: Tim Haley - Sun Microsystem ... ... ... >EXPORTED INTERFACE TABLE > > |Proposed |Specified | > |Stability |in what | >Interface Name |Classification |Document? | Comments >=============================================================================== > |Consolidation |This | > VFSFT_ACEMASKONACCESS |Private |Document | Registerable vfs > | | | feature > | | | > ATTR_NOACLCHECK | | | New flag for VOPs > | | | that modify/retrieve > | | | attributes and ACLs > | | | > V_ACE_MASK | | | New VOP_ACCESS() flag > | | | to accept an ACE-style > | | | access mask. > | | | > V_APPEND | | | New VOP_ACCESS() flag > | | | to check for ACE- > | | | enforced append-only > | | | access With of these new filesystem specific features being added, shouldn't new *pathconf() variables and getconf path_vars also be added to allow applications to determine if they can make use of these features in particular places in the file hierarchy? - Don From Rich.Brown@sun.com Tue Jul 10 09:16:27 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 l6AGGQQ5008122 for ; Tue, 10 Jul 2007 09:16:27 -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 l6AGEMg9014145; Tue, 10 Jul 2007 17:14:30 +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 <0JKZ00A131459500@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 10:14:29 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKZ00I0H144BUE0@brm-avmta-1.central.sun.com>; Tue, 10 Jul 2007 10:14:29 -0600 (MDT) 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 l6AGESPl003328; Tue, 10 Jul 2007 16:14:28 +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 <0JKZ00D010TST600@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Tue, 10 Jul 2007 10:14:28 -0600 (MDT) Received: from [129.147.9.42] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKZ00CP5144GS52@mail-amer.sun.com>; Tue, 10 Jul 2007 10:14:28 -0600 (MDT) Date: Tue, 10 Jul 2007 11:14:27 -0500 From: Rich Brown Subject: Re: Modified Access Checks for CIFS [PSARC/2007/403 FastTrack timeout 07/16/2007] In-reply-to: <200707101534.l6AFYGwV002796@spartan.SFBay.Sun.COM> Sender: Rich.Brown@sun.com To: Don Cragun Cc: PSARC-ext@sun.com, timh@spidey.central.sun.com, cifs-vfs-team@sun.com Message-id: <4693B063.10001@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: <200707101534.l6AFYGwV002796@spartan.SFBay.Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1606 Don Cragun wrote: >> Date: Mon, 09 Jul 2007 11:53:38 -0600 (MDT) >> From: Tim Haley - Sun Microsystem > ... ... ... >> EXPORTED INTERFACE TABLE >> >> |Proposed |Specified | >> |Stability |in what | >> Interface Name |Classification |Document? | Comments >> =============================================================================== >> |Consolidation |This | >> VFSFT_ACEMASKONACCESS |Private |Document | Registerable vfs >> | | | feature >> | | | >> ATTR_NOACLCHECK | | | New flag for VOPs >> | | | that modify/retrieve >> | | | attributes and ACLs >> | | | >> V_ACE_MASK | | | New VOP_ACCESS() flag >> | | | to accept an ACE-style >> | | | access mask. >> | | | >> V_APPEND | | | New VOP_ACCESS() flag >> | | | to check for ACE- >> | | | enforced append-only >> | | | access > > With of these new filesystem specific features being added, shouldn't > new *pathconf() variables and getconf path_vars also be added to allow > applications to determine if they can make use of these features in > particular places in the file hierarchy? > > - Don > Applications won't have any control over how the access checks are done. There are no changes proposed to allow applications to use ACE-style permissions. For now, the CIFS server will be the only entity making use of ACE-style access checks and requesting that ACL checks be skipped. If, at some point, a new/modified API were required to give applications that ability, then a new pathconf variable would be a good idea. Thanks, Rich From Timothy.Haley@sun.com Wed Jul 11 13:12:11 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 l6BKCBvh005802 for ; Wed, 11 Jul 2007 13:12:11 -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 l6BKAEbU026311; Wed, 11 Jul 2007 13:10:15 -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 <0JL100G1P6P21G00@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 14:10:14 -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 <0JL100DFS6P13I60@brm-avmta-1.central.sun.com>; Wed, 11 Jul 2007 14:10:13 -0600 (MDT) 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 l6BKACLE016679; Wed, 11 Jul 2007 20:10:12 +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 <0JL1003016D7HR00@mail-amer.sun.com> (original mail from Timothy.Haley@Sun.COM); Wed, 11 Jul 2007 14:10:12 -0600 (MDT) Received: from spidey.Central.Sun.COM ([172.20.25.27]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JL100COF6P0GT51@mail-amer.sun.com>; Wed, 11 Jul 2007 14:10:12 -0600 (MDT) Date: Wed, 11 Jul 2007 14:09:29 -0600 From: Tim Haley Subject: Re: Modified Access Checks for CIFS [PSARC/2007/403 FastTrack timeout 07/16/2007] In-reply-to: <200707091753.l69Hrc99011117@spidey.central.sun.com> Sender: Timothy.Haley@sun.com To: PSARC-ext@sun.com Cc: cifs-vfs-team@sun.com Message-id: <469538F9.6010901@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: <200707091753.l69Hrc99011117@spidey.central.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070618) Status: RO Content-Length: 59 This case was approved during today's PSARC meeting. -tim