From Darren.Moffat@sun.com Thu May 31 03:31:00 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 l4VAV0M4015092 for ; Thu, 31 May 2007 03:31:00 -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 l4VATcTu019113; Thu, 31 May 2007 03:29:39 -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 <0JIW0010VIHD2J00@brm-avmta-1.central.sun.com>; Thu, 31 May 2007 04:29:37 -0600 (MDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIW007LEIHC8OE0@brm-avmta-1.central.sun.com>; Thu, 31 May 2007 04:29:37 -0600 (MDT) 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 l4VATasg020501; Thu, 31 May 2007 10:29:36 +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 <0JIW00301IEQ7000@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 31 May 2007 11:29:36 +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 <0JIW00L92IH9RK30@d1-emea-09.sun.com>; Thu, 31 May 2007 11:29:34 +0100 (BST) Date: Thu, 31 May 2007 11:29:33 +0100 From: Darren J Moffat Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200705301919.l4UJJJKE004851@spidey.central.sun.com> Sender: Darren.Moffat@sun.com To: Timothy Haley - Sun Microsystem Cc: PSARC-ext@sun.com, Mark.Shellenbaum@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <465EA38D.6000704@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070424) Status: RO Content-Length: 1208 Timothy Haley - Sun Microsystem wrote: > 3.3 Third-Party Requested Attributes > > The following attributes have been requested by a third-party vendor > porting ZFS to a different platform. Solaris will not set these > attributes nor will there be any sematics associated with them. > Callers will be permitted to read the attributes. Attempts to set > these attributes will fail with EPERM. > > NODUMP > Solaris has no special semantics for this attribute. This one seems useful on Solaris. Assuming the name is reflective of its purpose it says to me that files with this attribute should not be included in backups. For example tar/cpio/pax might pay attention to that attribute but 'zfs send' would not. > The following files will be added to the top level directory in the > extended attribute namespace of all regular files: > > -r--r--r-- 1 root root 88 May 16 16:17 SUNWattr_ro > -rw-r--r-- 1 root root 484 May 16 16:17 SUNWattr_rw Why SUNW Rather than org.opensolaris as the prefix ? The latter would IMO be more appropriate today given these are OpenSolaris specific rather than "Sun Microsystems Inc" specific. -- Darren J Moffat From Mark.Shellenbaum@sun.com Thu May 31 09:27:18 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 l4VGRII5018669 for ; Thu, 31 May 2007 09:27:18 -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 l4VGPcqE037918; Thu, 31 May 2007 10:25:40 -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 <0JIW00707YZ8FI00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 09:25:56 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIW005JHYZ84W30@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 09:25:56 -0700 (PDT) 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 l4VGPt3v028818; Thu, 31 May 2007 16:25:55 +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 <0JIW00101YANY400@mail-amer.sun.com> (original mail from Mark.Shellenbaum@Sun.COM); Thu, 31 May 2007 10:25:55 -0600 (MDT) Received: from [172.20.25.34] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIW003DNYZ6NC63@mail-amer.sun.com>; Thu, 31 May 2007 10:25:55 -0600 (MDT) Date: Thu, 31 May 2007 10:25:54 -0600 From: Mark Shellenbaum Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465EA38D.6000704@Sun.COM> Sender: Mark.Shellenbaum@sun.com To: Darren J Moffat Cc: Timothy Haley - Sun Microsystem , PSARC-ext@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <465EF712.6050304@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 1781 Darren J Moffat wrote: > Timothy Haley - Sun Microsystem wrote: >> 3.3 Third-Party Requested Attributes >> >> The following attributes have been requested by a third-party vendor >> porting ZFS to a different platform. Solaris will not set these >> attributes nor will there be any sematics associated with them. >> Callers will be permitted to read the attributes. Attempts to set >> these attributes will fail with EPERM. >> >> NODUMP >> Solaris has no special semantics for this attribute. > > This one seems useful on Solaris. Assuming the name is reflective of > its purpose it says to me that files with this attribute should not be > included in backups. For example tar/cpio/pax might pay attention to > that attribute but 'zfs send' would not. > Yes, we can allow the NODUMP attribute to be set, but RFEs would need to be opened for the various archivers to pay attention to the attribute. >> The following files will be added to the top level directory in the >> extended attribute namespace of all regular files: >> >> -r--r--r-- 1 root root 88 May 16 16:17 SUNWattr_ro >> -rw-r--r-- 1 root root 484 May 16 16:17 SUNWattr_rw > > Why SUNW Rather than org.opensolaris as the prefix ? The latter would > IMO be more appropriate today given these are OpenSolaris specific > rather than "Sun Microsystems Inc" specific. > The SUNW prefix was chosen because of some wording in fsattr(5) which states that the SUNW prefix would be used for Sun specific attributes. I'm fine with changing it to the following if you feel strongly about it. OPENSOLARISattr_rw, and OPENSOLARISattr_ro If we do this change then then fsattr(5) man page would need to be updated to include the OPENSOLARIS prefix. -Mark From Nicolas.Williams@sun.com Thu May 31 09:37:19 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 l4VGbIpN019724 for ; Thu, 31 May 2007 09:37:18 -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 l4VGZqqC010560; Thu, 31 May 2007 17:35:53 +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 <0JIW0030BZFSY800@brm-avmta-1.central.sun.com>; Thu, 31 May 2007 10:35:52 -0600 (MDT) Received: from binky.central.sun.com ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIW00IETZFRNJA0@brm-avmta-1.central.sun.com>; Thu, 31 May 2007 10:35:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4VGYPns000775; Thu, 31 May 2007 11:34:25 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4VGYPTM000774; Thu, 31 May 2007 11:34:25 -0500 (CDT) Date: Thu, 31 May 2007 11:34:25 -0500 From: Nicolas Williams Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465EF712.6050304@Sun.COM> To: Mark Shellenbaum Cc: Darren J Moffat , Mark.Maybee@sun.com, Timothy Haley - Sun Microsystem , PSARC-ext@sun.com, Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <20070531163425.GO27420@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1144 On Thu, May 31, 2007 at 10:25:54AM -0600, Mark Shellenbaum wrote: > Darren J Moffat wrote: > >Why SUNW Rather than org.opensolaris as the prefix ? The latter would > >IMO be more appropriate today given these are OpenSolaris specific > >rather than "Sun Microsystems Inc" specific. Oh, interesting question. The point of the prefix is to prevent naming conflicts in a namespace with no preset name allocation rules. But note that there is an IANA registry for the corresponding NFSv4 named attribute namespace (see section 17.1 of RFC3530); I've not checked if this is changing in NFSv4.1. Should the ARC ask that these attributes be registered with the IANA? Do note that the process set out by section 17.1 of RFC3530 is rather painful, requiring publication of an Informational RFC in order to register any named attributes. I agree that a prefix that reflects the OpenSolaris name rather than the Sun stock symbol seems preferable. > If we do this change then then fsattr(5) man page would need to be > updated to include the OPENSOLARIS prefix. Yeah, though I don't like so many capital letters, but that's just me :) Nico -- From Darren.Moffat@sun.com Thu May 31 11:30:06 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 l4VIU4CH002761 for ; Thu, 31 May 2007 11:30:05 -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 l4VISfjw012242; Fri, 1 Jun 2007 02:28:42 +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 <0JIX00C0P4NSMC00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 11:28:40 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIX00C7U4NRHT00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 11:28:40 -0700 (PDT) Received: from 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 l4VIScTl006592; Thu, 31 May 2007 18:28:38 +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 <0JIX008014LN7400@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 31 May 2007 19:28:38 +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 <0JIX00I8D4NQE110@d1-emea-09.sun.com>; Thu, 31 May 2007 19:28:38 +0100 (BST) Date: Thu, 31 May 2007 19:28:35 +0100 From: Darren J Moffat Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465EF712.6050304@Sun.COM> Sender: Darren.Moffat@sun.com To: Mark Shellenbaum Cc: Timothy Haley - Sun Microsystem , PSARC-ext@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <465F13D3.4070706@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070424) Status: RO Content-Length: 827 Mark Shellenbaum wrote: >> Why SUNW Rather than org.opensolaris as the prefix ? The latter would >> IMO be more appropriate today given these are OpenSolaris specific >> rather than "Sun Microsystems Inc" specific. >> > > The SUNW prefix was chosen because of some wording in fsattr(5) which > states that the SUNW prefix would be used for Sun specific attributes. > I'm fine with changing it to the following if you feel strongly about it. but this isn't a Sun application it is the OpenSolaris kernel. I get the point of the paragraph though it was preallocating that as vendor space. > OPENSOLARISattr_rw, and OPENSOLARISattr_ro Why OPENSOLARIS rather than the much more common reverse DNS domain style that is used in so many other places ? org.opensolaris.attr_ro org.opensolaris.attr_rw -- Darren J Moffat From Mark.Shellenbaum@Sun.COM Thu May 31 11:42:37 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 l4VIgbNo004008 for ; Thu, 31 May 2007 11:42:37 -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 l4VIf6dJ023487; Thu, 31 May 2007 19:41:14 +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 <0JIX00D0158P8M00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 11:41:13 -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 <0JIX00CT458OHZ00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 11:41:13 -0700 (PDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4VIfCWn001558; Thu, 31 May 2007 18:41: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 <0JIX00E0152D0Q00@mail-amer.sun.com> (original mail from Mark.Shellenbaum@Sun.COM); Thu, 31 May 2007 12:41:12 -0600 (MDT) Received: from [172.20.25.34] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIX0032R58OXQ35@mail-amer.sun.com>; Thu, 31 May 2007 12:41:12 -0600 (MDT) Date: Thu, 31 May 2007 12:41:12 -0600 From: Mark Shellenbaum Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465F13D3.4070706@Sun.COM> Sender: Mark.Shellenbaum@Sun.COM To: Darren J Moffat Cc: Timothy Haley - Sun Microsystem , PSARC-ext@Sun.COM, Christopher.Kirby@Sun.COM, cifs-vfs-team@Sun.COM, Mark.Maybee@Sun.COM, Richard.Morris@Sun.COM Message-id: <465F16C8.8040806@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> <465F13D3.4070706@Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 930 Darren J Moffat wrote: > Mark Shellenbaum wrote: >>> Why SUNW Rather than org.opensolaris as the prefix ? The latter would >>> IMO be more appropriate today given these are OpenSolaris specific >>> rather than "Sun Microsystems Inc" specific. >>> >> >> The SUNW prefix was chosen because of some wording in fsattr(5) which >> states that the SUNW prefix would be used for Sun specific attributes. >> I'm fine with changing it to the following if you feel strongly about it. > > but this isn't a Sun application it is the OpenSolaris kernel. > > I get the point of the paragraph though it was preallocating that as > vendor space. > >> OPENSOLARISattr_rw, and OPENSOLARISattr_ro > > Why OPENSOLARIS rather than the much more common reverse DNS domain > style that is used in so many other places ? org.opensolaris.attr_ro > org.opensolaris.attr_rw > Thats fine, I was just trying to keep the name shorter. -Mark From Nicolas.Williams@sun.com Thu May 31 11:58:02 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 l4VIw29E006177 for ; Thu, 31 May 2007 11:58:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l4VIuaYk012023; Thu, 31 May 2007 11:56:38 -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 <0JIX00D315YDXM00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 11:56:37 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIX00CZ85YCI310@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 11:56:36 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4VItA7a001124; Thu, 31 May 2007 13:55:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4VItAgV001123; Thu, 31 May 2007 13:55:10 -0500 (CDT) Date: Thu, 31 May 2007 13:55:10 -0500 From: Nicolas Williams Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465F13D3.4070706@Sun.COM> To: Darren J Moffat Cc: Mark Shellenbaum , Timothy Haley - Sun Microsystem , PSARC-ext@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <20070531185509.GB27420@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> <465F13D3.4070706@Sun.COM> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 590 On Thu, May 31, 2007 at 07:28:35PM +0100, Darren J Moffat wrote: > Mark Shellenbaum wrote: > >>Why SUNW Rather than org.opensolaris as the prefix ? The latter would > >>IMO be more appropriate today given these are OpenSolaris specific > >>rather than "Sun Microsystems Inc" specific. > >> > > > >The SUNW prefix was chosen because of some wording in fsattr(5) which > >states that the SUNW prefix would be used for Sun specific attributes. > >I'm fine with changing it to the following if you feel strongly about it. > > but this isn't a Sun application it is the OpenSolaris kernel. From the point of view of RFC3530 (NFSv4) it doesn't matter that it's Status: RO the kernel using a given named attribute -- to RFC3530 the kernel looks like an application when it uses a named attribute. Yes, it seems rather silly that RFC3530 didn't reserve named attr namespaces for use by OS implementors, but IIRC that had to do with discouraging the use of OS-specific named attrs that could balkanize NFSv4 interop. > >OPENSOLARISattr_rw, and OPENSOLARISattr_ro > > Why OPENSOLARIS rather than the much more common reverse DNS domain > style that is used in so many other places ? org.opensolaris.attr_ro > org.opensolaris.attr_rw Whatever we use will be arbitrary. I don't like so many caps; I too prefer org.opensolaris.*. Nico -- From jek3@sun.com Thu May 31 13:10:35 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 l4VKAYsM014141 for ; Thu, 31 May 2007 13:10:35 -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 l4VK8vab021413; Thu, 31 May 2007 21:09:10 +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 <0JIX00H079B9I800@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 13:09:09 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIX00CFR9B9I060@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 13:09:09 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4VK98sU544752; Thu, 31 May 2007 13:09:08 -0700 (PDT) Date: Thu, 31 May 2007 10:08:48 -1000 From: Joseph Kowalski Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465EF712.6050304@Sun.COM> To: Mark Shellenbaum Cc: Darren J Moffat , Timothy Haley - Sun Microsystem , PSARC-ext@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <465F2B50.7000404@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1395 Mark Shellenbaum wrote: >> >> Why SUNW Rather than org.opensolaris as the prefix ? The latter would >> IMO be more appropriate today given these are OpenSolaris specific >> rather than "Sun Microsystems Inc" specific. >> > > The SUNW prefix was chosen because of some wording in fsattr(5) which > states that the SUNW prefix would be used for Sun specific attributes. > I'm fine with changing it to the following if you feel strongly about it. > > OPENSOLARISattr_rw, and OPENSOLARISattr_ro > > If we do this change then then fsattr(5) man page would need to be > updated to include the OPENSOLARIS prefix. Just my two cents on naming. If we start using OPENSOLARIS rather than SUNW, people will wonder what is different. The only point of either of these is to partition the namespace. We chose SUNW in a day where the players we were concerned about all had Stock Symbols, but even that was poor because it ignored foreign exchanges (which may collide). IMHO, this was never a good idea, but we did it. In retrospect, perhaps a product oriented name would have been better - SOLARIS or SUNOS - but that's water long under the bridge. My point is that unless the letters SUNW cause anybody serious grief, we should just continue with their use and just write it off to history should anybody question it. More names, with equivalent meanings, don't do us much good. - jek3 From Garrett.Damore@sun.com Thu May 31 13:32:20 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 l4VKWJKI016037 for ; Thu, 31 May 2007 13:32:19 -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 l4VKUtwM028383; Thu, 31 May 2007 21:30:57 +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 <0JIX00K0JABIWZ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 May 2007 13:30:54 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIX00LPMABHRDD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 May 2007 13:30:53 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l4VKUrI1000196; Thu, 31 May 2007 13:30:53 -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 <0JIX00F01A5E1Y00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM); Thu, 31 May 2007 13:30:53 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JIX00KKUABCVSF0@fe-sfbay-10.sun.com>; Thu, 31 May 2007 13:30:48 -0700 (PDT) Date: Thu, 31 May 2007 13:29:14 -0700 From: "Garrett D'Amore" Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465F2B50.7000404@sun.com> Sender: Garrett.Damore@sun.com To: Joseph Kowalski Cc: Mark Shellenbaum , Darren J Moffat , Timothy Haley - Sun Microsystem , psarc-ext@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <465F301A.8030502@sun.com> Organization: Sun Microsystems 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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> <465F2B50.7000404@sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2013 Joseph Kowalski wrote: > Mark Shellenbaum wrote: >>> >>> Why SUNW Rather than org.opensolaris as the prefix ? The latter >>> would IMO be more appropriate today given these are OpenSolaris >>> specific rather than "Sun Microsystems Inc" specific. >>> >> >> The SUNW prefix was chosen because of some wording in fsattr(5) which >> states that the SUNW prefix would be used for Sun specific >> attributes. I'm fine with changing it to the following if you feel >> strongly about it. >> >> OPENSOLARISattr_rw, and OPENSOLARISattr_ro >> >> If we do this change then then fsattr(5) man page would need to be >> updated to include the OPENSOLARIS prefix. > Just my two cents on naming. > > If we start using OPENSOLARIS rather than SUNW, people will wonder > what is different. The only point of either > of these is to partition the namespace. > > We chose SUNW in a day where the players we were concerned about all > had Stock Symbols, but even that was > poor because it ignored foreign exchanges (which may collide). IMHO, > this was never a good idea, but we did it. > In retrospect, perhaps a product oriented name would have been better > - SOLARIS or SUNOS - but that's water > long under the bridge. > > My point is that unless the letters SUNW cause anybody serious grief, > we should just continue with their use and > just write it off to history should anybody question it. More names, > with equivalent meanings, don't do us much good. +1 Further, if we go down this trend, are we going to have to start changing all those old SUNW packages, etc. Yikes, I hope not. Also, I find the reverse DNS naming scheme dissatisfying ... it makes everything quite a bit longer than it really needs to be to provide the separation of the namespace that is desired. It also ignores the bit that not everyone who wants to participate will have a DNS domain name, or that the domainname will not change over time. (E.g. due to mergers, buyouts, insolvency, or rebranding.) -- Garrett From Nicolas.Williams@sun.com Thu May 31 13:41:45 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 l4VKfje3016795 for ; Thu, 31 May 2007 13:41:45 -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 l4VKdwJm033341; Thu, 31 May 2007 14:40:05 -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 <0JIX00L4FAR7RY00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 May 2007 13:40:19 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIX00LU8AR6R6E0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 May 2007 13:40:19 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4VKcqmP001176; Thu, 31 May 2007 15:38:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4VKcqOu001175; Thu, 31 May 2007 15:38:52 -0500 (CDT) Date: Thu, 31 May 2007 15:38:52 -0500 From: Nicolas Williams Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465F301A.8030502@sun.com> To: "Garrett D'Amore" Cc: Joseph Kowalski , Mark.Maybee@sun.com, Mark Shellenbaum , Timothy Haley - Sun Microsystem , psarc-ext@sun.com, Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <20070531203851.GD27420@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> <465F2B50.7000404@sun.com> <465F301A.8030502@sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1161 On Thu, May 31, 2007 at 01:29:14PM -0700, Garrett D'Amore wrote: > Joseph Kowalski wrote: > >My point is that unless the letters SUNW cause anybody serious grief, > >we should just continue with their use and just write it off to > >history should anybody question it. More names, with equivalent > >meanings, don't do us much good. > > +1 > > Further, if we go down this trend, are we going to have to start > changing all those old SUNW packages, etc. Yikes, I hope not. I didn't see Darren suggest that old things called SUNW* be renamed, nor did I suggest it; noone suggested that. Nor do I think there's a slippery slope towards that. > Also, I find the reverse DNS naming scheme dissatisfying ... it makes > everything quite a bit longer than it really needs to be to provide the > separation of the namespace that is desired. It also ignores the bit > that not everyone who wants to participate will have a DNS domain name, > or that the domainname will not change over time. (E.g. due to mergers, > buyouts, insolvency, or rebranding.) Yes, all possible names will suck, which is the best argument for sticking to SUNW* here. Nico -- From jek3@sun.com Thu May 31 13:46: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 l4VKkvto017200 for ; Thu, 31 May 2007 13:46:57 -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 l4VKjUnw007244; Thu, 31 May 2007 13:45:33 -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 <0JIX00K0JAZUP600@brm-avmta-1.central.sun.com>; Thu, 31 May 2007 14:45:31 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIX008C4AZQUFA0@brm-avmta-1.central.sun.com>; Thu, 31 May 2007 14:45:26 -0600 (MDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l4VKjOeI552094; Thu, 31 May 2007 13:45:25 -0700 (PDT) Date: Thu, 31 May 2007 10:45:04 -1000 From: Joseph Kowalski Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465F301A.8030502@sun.com> To: "Garrett D'Amore" Cc: Mark Shellenbaum , Darren J Moffat , Timothy Haley - Sun Microsystem , psarc-ext@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <465F33D0.7090706@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> <465F2B50.7000404@sun.com> <465F301A.8030502@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 891 Garrett D'Amore wrote: > Also, I find the reverse DNS naming scheme dissatisfying ... it makes > everything quite a bit longer than it really needs to be to provide > the separation of the namespace that is desired. It also ignores the > bit that not everyone who wants to participate will have a DNS domain > name, or that the domainname will not change over time. (E.g. due to > mergers, buyouts, insolvency, or rebranding.) True enough, but it is better than Stock Symbols (How much would a domain name cost me? How much would a stock symbol cost me?) More importantly, its the fairly widely accepted convention these days. My only point is that Solaris/OpenSolaris/Sun/whatever is special. Somebody would have to be from another planet to step on SUNW. A discussion as to what the suggested form for others should be is a separate discussion - not this case. - jek3 From Nicolas.Williams@sun.com Thu May 31 14:07:06 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 l4VL75kY019368 for ; Thu, 31 May 2007 14:07:06 -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 l4VL5Yg6010422; Thu, 31 May 2007 22:05:38 +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 <0JIX0010XBXD5300@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 May 2007 14:05:37 -0700 (PDT) Received: from binky.central.sun.com ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JIX00L49BXDR3G0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 31 May 2007 14:05:37 -0700 (PDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.13.8+Sun/8.13.6) with ESMTP id l4VL4BKX001252; Thu, 31 May 2007 16:04:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.13.8+Sun/8.13.8/Submit) id l4VL4AVL001251; Thu, 31 May 2007 16:04:10 -0500 (CDT) Date: Thu, 31 May 2007 16:04:10 -0500 From: Nicolas Williams Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465F33D0.7090706@sun.com> To: Joseph Kowalski Cc: "Garrett D'Amore" , Mark.Maybee@sun.com, Mark Shellenbaum , Timothy Haley - Sun Microsystem , psarc-ext@sun.com, Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <20070531210410.GH27420@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> <465F2B50.7000404@sun.com> <465F301A.8030502@sun.com> <465F33D0.7090706@sun.com> X-Authentication-warning: binky.central.sun.com: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2485 On Thu, May 31, 2007 at 10:45:04AM -1000, Joseph Kowalski wrote: > Garrett D'Amore wrote: > >Also, I find the reverse DNS naming scheme dissatisfying ... it makes > >everything quite a bit longer than it really needs to be to provide > >the separation of the namespace that is desired. It also ignores the > >bit that not everyone who wants to participate will have a DNS domain > >name, or that the domainname will not change over time. (E.g. due to > >mergers, buyouts, insolvency, or rebranding.) > True enough, but it is better than Stock Symbols (How much would a > domain name cost me? How much would a stock symbol cost me?) More > importantly, its the fairly widely accepted convention these days. > > My only point is that Solaris/OpenSolaris/Sun/whatever is special. > Somebody would have to be from another planet to step on SUNW. > > A discussion as to what the suggested form for others should be is a > separate discussion - not this case. IF RFC3530 had provided a light-weight registration procedure for the named attribute namespace, and IF we could treat that as authoritative for Solaris' extended attributes namespace, THEN there would be NO NEED for any prefix, though we might pick a very generic prefix, like "system." to help avoid conflicts with apps that use unregistered named attributes. BUT, NEITHER does RFC3530 provide such a light-weight registration procedure, NOR is it obvious that we could use its named attribute registry as authoritative for Solaris' extended attrs namespace: though fsattr(5) is quite unclear on that point, as it does reference RFC3530 and says that NFSv4 named attrs and Solaris extended attrs are "equivalent," but then misrepresents what RFC3530 says about this namespace. (RFC3530 allows one to use any named attr name one wants but encourages folks to follow a very heavy-weight procedure for registering them! Guess how many app developers will bother to register their named attr names? What is the point of such a registry if noone will ever use it?) I think we do need an authoritative registry for this namespace, and its registration procedures ought to be exceedingly light-weight, else noone will register their named attr names. IANA is as good a registrar as any. I think advice to the IETF NFSv4 WG to loosen the registration procedures is in order. Advice to the i-team to register these attributes, even though the current process is painful, seems in order as well. *sigh* Nico -- From Spencer.Shepler@sun.com Thu May 31 21:03:36 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 l5143aAU029040 for ; Thu, 31 May 2007 21:03:36 -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 l5142GLx005348; Thu, 31 May 2007 21:02:16 -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 <0JIX00I03V7SBX00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 21:02:16 -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 <0JIX0025BV7R8RC0@nwk-avmta-2.sfbay.sun.com>; Thu, 31 May 2007 21:02:16 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5142FmR009561; Fri, 01 Jun 2007 04:02:15 +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 <0JIX00501UR08K00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM); Thu, 31 May 2007 22:02:15 -0600 (MDT) Received: from [10.1.194.251] (sca-ea-proxy-2.Sun.COM [192.18.43.27]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIX00GKNV7N3350@mail-amer.sun.com>; Thu, 31 May 2007 22:02:15 -0600 (MDT) Date: Thu, 31 May 2007 23:02:10 -0500 From: Spencer Shepler Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200705301919.l4UJJJKE004851@spidey.central.sun.com> Sender: Spencer.Shepler@sun.com To: Timothy Haley - Sun Microsystem Cc: PSARC-ext@sun.com, Mark.Shellenbaum@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <503E94C3-AAB6-43AE-B3A8-4D82114A6721@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> Status: RO Content-Length: 1652 On May 30, 2007, at 2:19 PM, Timothy Haley - Sun Microsystem wrote: > > 2.0 OVERVIEW > > The Solaris CIFS project requires file system support for a > number of > "system" and opaque file attributes. For file systems that fully > support CIFS, the system attributes will be present on all file > system objects and the file system will need to update the > attribute(s) as a result of various file system operations such as > data written to a file. The CIFS server and application programs > will also need to be able to query/update the attributes when > needed. Additionally, the CIFS server will be using the Solaris > extended attribute model for storing a number of opaque file > attributes. ZFS will be the primary underlying file system for the > CIFS server. > > In order to accommodate the existing extended attribute aware > utilities in Solaris, the new attributes will be exposed via the > existing Solaris extended attribute model. The new attributes will > be grouped in a number of SUNWattr* files that will have multiple > attributes in a single file composed as a packed nvlist. Since all I assume the attributes will be XDR packed. > > 4.3.1 NFSv4 Support for Optional Attributes (Potential Future Work) > > The NFSv4 protocol has an attribute model that supports extensions. > In fact, two of the new attributes (ARCHIVE and HIDDEN) are part of > the "recommended" list of attributes for a client and server and SYSTEM > implementation. The Solaris NFSv4 client and server could be > modified to support the new, optional attributes as specified by > the protocol. Spencer From Mark.Shellenbaum@sun.com Fri Jun 1 07:06:17 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 l51E6HEf022774 for ; Fri, 1 Jun 2007 07:06:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l51E4nwr021447; Fri, 1 Jun 2007 07:04:57 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JIY0070TN481O00@brm-avmta-1.central.sun.com>; Fri, 01 Jun 2007 08:04:56 -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 <0JIY00LB9N479690@brm-avmta-1.central.sun.com>; Fri, 01 Jun 2007 08:04:55 -0600 (MDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l51E4tUF028883; Fri, 01 Jun 2007 14:04:55 +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 <0JIY00M01MMTT500@mail-amer.sun.com> (original mail from Mark.Shellenbaum@Sun.COM); Fri, 01 Jun 2007 08:04:55 -0600 (MDT) Received: from [172.20.25.34] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIY00370N46LDN1@mail-amer.sun.com>; Fri, 01 Jun 2007 08:04:55 -0600 (MDT) Date: Fri, 01 Jun 2007 08:04:54 -0600 From: Mark Shellenbaum Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <503E94C3-AAB6-43AE-B3A8-4D82114A6721@sun.com> Sender: Mark.Shellenbaum@sun.com To: Spencer Shepler Cc: Timothy Haley - Sun Microsystem , PSARC-ext@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <46602786.60408@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <503E94C3-AAB6-43AE-B3A8-4D82114A6721@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 1247 Spencer Shepler wrote: > > On May 30, 2007, at 2:19 PM, Timothy Haley - Sun Microsystem wrote: >> >> 2.0 OVERVIEW >> >> The Solaris CIFS project requires file system support for a number of >> "system" and opaque file attributes. For file systems that fully >> support CIFS, the system attributes will be present on all file >> system objects and the file system will need to update the >> attribute(s) as a result of various file system operations such as >> data written to a file. The CIFS server and application programs >> will also need to be able to query/update the attributes when >> needed. Additionally, the CIFS server will be using the Solaris >> extended attribute model for storing a number of opaque file >> attributes. ZFS will be the primary underlying file system for the >> CIFS server. >> >> In order to accommodate the existing extended attribute aware >> utilities in Solaris, the new attributes will be exposed via the >> existing Solaris extended attribute model. The new attributes will >> be grouped in a number of SUNWattr* files that will have multiple >> attributes in a single file composed as a packed nvlist. Since all > > I assume the attributes will be XDR packed. Yes From Rich.Brown@sun.com Fri Jun 1 07:13:35 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 l51EDZC8023354 for ; Fri, 1 Jun 2007 07:13:35 -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 l51EC4En027713; Fri, 1 Jun 2007 15:12:13 +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 <0JIY0070JNG9HZ00@brm-avmta-1.central.sun.com>; Fri, 01 Jun 2007 08:12:09 -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 <0JIY00LHONG99490@brm-avmta-1.central.sun.com>; Fri, 01 Jun 2007 08:12:09 -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 l51EC9ir006224; Fri, 01 Jun 2007 14:12:09 +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 <0JIY00201N5N5J00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Fri, 01 Jun 2007 08:12:09 -0600 (MDT) Received: from [129.147.9.135] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIY003BBNG6LDN1@mail-amer.sun.com>; Fri, 01 Jun 2007 08:12:07 -0600 (MDT) Date: Fri, 01 Jun 2007 09:12:05 -0500 From: Rich Brown Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <503E94C3-AAB6-43AE-B3A8-4D82114A6721@sun.com> Sender: Rich.Brown@sun.com To: Spencer Shepler Cc: Timothy Haley - Sun Microsystem , PSARC-ext@sun.com, Mark.Shellenbaum@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <46602935.3060509@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <503E94C3-AAB6-43AE-B3A8-4D82114A6721@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 629 Spencer Shepler wrote: ... >> 4.3.1 NFSv4 Support for Optional Attributes (Potential Future Work) >> >> The NFSv4 protocol has an attribute model that supports extensions. >> In fact, two of the new attributes (ARCHIVE and HIDDEN) are part of >> the "recommended" list of attributes for a client and server > > and SYSTEM > >> implementation. The Solaris NFSv4 client and server could be >> modified to support the new, optional attributes as specified by >> the protocol. > I thought I missed one, but my eyes must have glazed over while looking through the spec. Good catch, Spencer. We'll add that. Rich From Timothy.Haley@Sun.COM Fri Jun 1 08:58:11 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 l51FwBvf003285 for ; Fri, 1 Jun 2007 08:58:11 -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 l51FunBe004842 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 1 Jun 2007 16:56:49 +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 <0JIY00K03SAOEI00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Jun 2007 08:56:48 -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 <0JIY00HPLSAO6V20@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Jun 2007 08:56:48 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l51FumDl027781 for ; Fri, 01 Jun 2007 15:56: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 <0JIY00601S94ZA00@mail-amer.sun.com> (original mail from Timothy.Haley@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Jun 2007 09:56:48 -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 <0JIY00IS5SAIT735@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 01 Jun 2007 09:56:46 -0600 (MDT) Date: Fri, 01 Jun 2007 09:56:37 -0600 From: Tim Haley Subject: [Fwd: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack] Sender: Timothy.Haley@Sun.COM To: psarc-ext@Sun.COM Cc: "Richard L. Hamilton" Message-id: <466041B5.3070200@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 2772 Guess the mechanics of the jive interface still don't quite work, so forwarding this comment from Richard L Hamilton: -------- Original Message -------- Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack Date: Fri, 01 Jun 2007 04:35:38 -0700 (PDT) From: Richard L. Hamilton To: opensolaris-arc@opensolaris.org > > > > 2.0 OVERVIEW > > > > The Solaris CIFS project requires file system > support for a > > number of > > "system" and opaque file attributes. For file > systems that fully > > support CIFS, the system attributes will be > present on all file > > system objects and the file system will need to > update the > > attribute(s) as a result of various file system > operations such as > > data written to a file. The CIFS server and > application programs > > will also need to be able to query/update the > attributes when > > needed. Additionally, the CIFS server will be > using the Solaris > > extended attribute model for storing a number of > opaque file > > attributes. ZFS will be the primary underlying > file system for the > > CIFS server. > > > > In order to accommodate the existing extended > attribute aware > > utilities in Solaris, the new attributes will be > exposed via the > > existing Solaris extended attribute model. The > new attributes will > > be grouped in a number of SUNWattr* files that > will have multiple > > attributes in a single file composed as a packed > nvlist. Since all > > I assume the attributes will be XDR packed. > > > > 4.3.1 NFSv4 Support for Optional Attributes > (Potential Future Work) > > > > The NFSv4 protocol has an attribute model that > supports extensions. > > In fact, two of the new attributes (ARCHIVE and > HIDDEN) are part of > > the "recommended" list of attributes for a client > and server > > and SYSTEM > > > implementation. The Solaris NFSv4 client and > server could be > > modified to support the new, optional attributes > as specified by > > the protocol. Has the storage overhead of multiple extended attribute "files" associated with every filesystem object been considered? Or the impact of multiplying the total namespace (of file and attribute names) on the directory handling facilities of the OS? Seems to me that everything the CIFS server needs should be packed into at most a single extended attribute "file" per object. On the other side of things, maybe fsattr(5) (at least as of the SXDE version of the page on docs.sun.com) ought to update its references to mention something more current than the NFSv4 draft standard. This message posted from opensolaris.org _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org From chris.kirby@sun.com Fri Jun 1 09:10:44 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 l51GAh8S004356 for ; Fri, 1 Jun 2007 09:10:43 -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 l51G9DOD029584 for <@newsunmail1brm.central.sun.com:psarc-ext@sun.com>; Sat, 2 Jun 2007 00:09:21 +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 <0JIY00F0TSVLMG00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 01 Jun 2007 10:09:21 -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 <0JIY00C3WSVLAW50@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 01 Jun 2007 10:09:21 -0600 (MDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l51G9KPN003361 for ; Fri, 01 Jun 2007 16:09:20 +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 <0JIY00701SL4AO00@mail-amer.sun.com> (original mail from chris.kirby@sun.com) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 01 Jun 2007 10:09:20 -0600 (MDT) Received: from [192.168.1.100] ([129.150.32.37]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JIY00HXUSVKIH10@mail-amer.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 01 Jun 2007 10:09:20 -0600 (MDT) Date: Fri, 01 Jun 2007 11:09:19 -0500 From: Chris Kirby Subject: Re: [Fwd: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack] In-reply-to: <466041B5.3070200@sun.com> Sender: Christopher.Kirby@sun.com To: Tim Haley Cc: psarc-ext@sun.com, "Richard L. Hamilton" Message-id: <466044AF.7070001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <466041B5.3070200@sun.com> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) Status: RO Content-Length: 802 Tim Haley wrote: > Guess the mechanics of the jive interface still don't quite work, so > forwarding this comment from Richard L Hamilton: > > -------- Original Message -------- > Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack > Date: Fri, 01 Jun 2007 04:35:38 -0700 (PDT) > From: Richard L. Hamilton > To: opensolaris-arc@opensolaris.org > > > Has the storage overhead of multiple extended attribute "files" associated > with every filesystem object been considered? Or the impact of multiplying > the total namespace (of file and attribute names) on the directory handling > facilities of the OS? See section 4.1 of the document. There is no additional disk storage required to present system attributes in the extended attribute namespace. -Chris From Rich.Brown@sun.com Mon Jun 4 09:23:09 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 l54GN9X9024626 for ; Mon, 4 Jun 2007 09:23:09 -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 l54GLjOu008495; Mon, 4 Jun 2007 09:21:45 -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 <0JJ40070FDG9VW00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 04 Jun 2007 09:21:45 -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 <0JJ4005JFDG89S30@nwk-avmta-1.sfbay.Sun.COM>; Mon, 04 Jun 2007 09:21:44 -0700 (PDT) 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 l54GLiA1005412; Mon, 04 Jun 2007 16:21: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 <0JJ400H01D8GHC00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Mon, 04 Jun 2007 10:21:44 -0600 (MDT) Received: from [129.147.9.135] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJ4003OYDG6NCR4@mail-amer.sun.com>; Mon, 04 Jun 2007 10:21:43 -0600 (MDT) Date: Mon, 04 Jun 2007 11:21:42 -0500 From: Rich Brown Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <20070531210410.GH27420@Sun.COM> Sender: Rich.Brown@sun.com To: psarc-ext@sun.com Cc: Nicolas Williams , Joseph Kowalski , "Garrett D'Amore" , Mark.Maybee@sun.com, Mark Shellenbaum , Timothy Haley - Sun Microsystem , Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <46643C16.8020809@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> <465F2B50.7000404@sun.com> <465F301A.8030502@sun.com> <465F33D0.7090706@sun.com> <20070531210410.GH27420@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 4548 Nicolas Williams wrote: > On Thu, May 31, 2007 at 10:45:04AM -1000, Joseph Kowalski wrote: >> Garrett D'Amore wrote: >>> Also, I find the reverse DNS naming scheme dissatisfying ... it makes >>> everything quite a bit longer than it really needs to be to provide >>> the separation of the namespace that is desired. It also ignores the >>> bit that not everyone who wants to participate will have a DNS domain >>> name, or that the domainname will not change over time. (E.g. due to >>> mergers, buyouts, insolvency, or rebranding.) >> True enough, but it is better than Stock Symbols (How much would a >> domain name cost me? How much would a stock symbol cost me?) More >> importantly, its the fairly widely accepted convention these days. >> >> My only point is that Solaris/OpenSolaris/Sun/whatever is special. >> Somebody would have to be from another planet to step on SUNW. >> >> A discussion as to what the suggested form for others should be is a >> separate discussion - not this case. > > IF RFC3530 had provided a light-weight registration procedure for the > named attribute namespace, and IF we could treat that as authoritative > for Solaris' extended attributes namespace, THEN there would be NO NEED > for any prefix, though we might pick a very generic prefix, like > "system." to help avoid conflicts with apps that use unregistered named > attributes. > > BUT, NEITHER does RFC3530 provide such a light-weight registration > procedure, NOR is it obvious that we could use its named attribute > registry as authoritative for Solaris' extended attrs namespace: though > fsattr(5) is quite unclear on that point, as it does reference RFC3530 > and says that NFSv4 named attrs and Solaris extended attrs are > "equivalent," but then misrepresents what RFC3530 says about this > namespace. > > (RFC3530 allows one to use any named attr name one wants but encourages > folks to follow a very heavy-weight procedure for registering them! > Guess how many app developers will bother to register their named attr > names? What is the point of such a registry if noone will ever use it?) > > I think we do need an authoritative registry for this namespace, and its > registration procedures ought to be exceedingly light-weight, else noone > will register their named attr names. IANA is as good a registrar as > any. I think advice to the IETF NFSv4 WG to loosen the registration > procedures is in order. > > Advice to the i-team to register these attributes, even though the > current process is painful, seems in order as well. > > *sigh* > > Nico The system attribute files (SUNWattr_rw, SUNWattr_ro) are not intended to be used as NFS named attributes directly. The format of these files are nvpairs of the system attributes. I wouldn't expect all NFS clients and servers to recognize Solaris' nvpair format. In terms of NFS support for the system attributes contained in these files, see section 4.1 of the spec: 4.3.1 NFSv4 Support for Optional Attributes (Potential Future Work) The NFSv4 protocol has an attribute model that supports extensions. In fact, two of the new attributes (ARCHIVE and HIDDEN) are part of the "recommended" list of attributes for a client and server implementation. The Solaris NFSv4 client and server could be modified to support the new, optional attributes as specified by the protocol. This work is not currently funded. Note that SYSTEM needs to be added to the list. (Thanks Spencer!) Regarding the registration of named attributes, RFC3530 states: "the intent is to promote interoperability where common interest exists". But the team is not claiming interoperability with these two attribute files. Interoperability would happen with the attributes stored WITHIN these attribute files. Registering these attribute files with the IANA means that the project team would have to publish an informational RFC to state the name of the attributes (SUNWattr_rw and SUNWattr_ro) then describe the syntax and semantics of the named attribute contents. Any new attributes added to these files would require project teams to submit updates to the RFC. As Nico said, this is "a very heavy-weight procedure". Given that, I don't see the value for Sun in registering the system attribute files as named attributes for NFS through the IANA. I see it as a high cost for no gain. Not that we think that anyone is going to use SUNWattr_* (or whatever we decide on) but the IANA registration doesn't even claim to prevent name collisions. Rich From Nicolas.Williams@sun.com Mon Jun 4 10:25: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 l54HP1EA029186 for ; Mon, 4 Jun 2007 10:25:01 -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 l54HNZQM003384; Tue, 5 Jun 2007 01:23:36 +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 <0JJ400D0NGBBDE00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 04 Jun 2007 10:23:35 -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 <0JJ4005PBGBA9Y90@nwk-avmta-1.sfbay.Sun.COM>; Mon, 04 Jun 2007 10:23:34 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l54HNYoE015794; Mon, 04 Jun 2007 17:23: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 <0JJ400601G7DWF00@mail-amer.sun.com> (original mail from Nicolas.Williams@Sun.COM); Mon, 04 Jun 2007 11:23:34 -0600 (MDT) Received: from [129.153.131.95] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJ400IR2GB8T982@mail-amer.sun.com>; Mon, 04 Jun 2007 11:23:33 -0600 (MDT) Date: Mon, 04 Jun 2007 12:23:32 -0500 From: Nicolas.Williams@sun.com Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <46643C16.8020809@Sun.COM> Sender: Nicolas.Williams@sun.com To: Rich Brown Cc: psarc-ext@sun.com, Joseph Kowalski , "Garrett D'Amore" , Mark.Maybee@sun.com, Mark Shellenbaum , Timothy Haley - Sun Microsystem , Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <46644A94.1050005@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> <465F2B50.7000404@sun.com> <465F301A.8030502@sun.com> <465F33D0.7090706@sun.com> <20070531210410.GH27420@Sun.COM> <46643C16.8020809@Sun.COM> User-Agent: Thunderbird 1.5.0.8 (X11/20061110) Status: RO Content-Length: 2712 Rich Brown wrote: > The system attribute files (SUNWattr_rw, SUNWattr_ro) are not intended > to be used as NFS named attributes directly. The format of these files > are nvpairs of the system attributes. I wouldn't expect all NFS clients > and servers to recognize Solaris' nvpair format. I would expect a future project to make these attributes visible through NFSv4 to make each attribute visible as a separate named attribute, not all of them in one file with nvlist format. But then, perhaps we'd pursue different extensions to NFSv4 for this anyways. > Regarding the registration of named attributes, RFC3530 states: > "the intent is to promote interoperability where common interest exists". But surely also there is a namespace collision avoidance rationale. In the case of applications there is no problem since presumably two (or more) different apps using conflicting attribute names wouldn't share the same files. While in the case of the operating system as the application we could expect every file to have these attributes, so the namespace conflict avoidance issue matters. I suspect that the NFSv4 WG only intended for imlementors of clients and servers that rely on special named attributes to register them, whereas application developers wouldn't have to. Whatever. The WG chose a method too difficult to use, so we shan't (and if anyone insisted I'd suggest simply not allowing these SUNW attrs to be visible via NFSv4). > But the team is not claiming interoperability with these two attribute > files. Interoperability would happen with the attributes stored WITHIN > these attribute files. No, the team isn't claiming interop, but folks outside Sun might like to support these attributes -- I believe that's what the RFC wants us to facilitate. > Registering these attribute files with the IANA means that the project > team would have to publish an informational RFC to state the name of the > attributes (SUNWattr_rw and SUNWattr_ro) then describe the syntax and > semantics of the named attribute contents. Any new attributes added > to these files would require project teams to submit updates to the RFC. > As Nico said, this is "a very heavy-weight procedure". > > Given that, I don't see the value for Sun in registering the system > attribute files as named attributes for NFS through the IANA. > I see it as a high cost for no gain. Not that we think that anyone > is going to use SUNWattr_* (or whatever we decide on) but the IANA > registration doesn't even claim to prevent name collisions. Really? No NFSv4 client implementor would see any value in understanding and supporting the use of these attributes? I somehow doubt that. Nico -- From Rich.Brown@Sun.COM Mon Jun 4 11:14: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 l54IE98f001339 for ; Mon, 4 Jun 2007 11:14:09 -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 l54ICafj020334; Tue, 5 Jun 2007 02:12:44 +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 <0JJ400E05IL6LI00@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Jun 2007 11:12:42 -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 <0JJ400AL5IL6XH50@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Jun 2007 11:12:42 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l54ICgjv013482; Mon, 04 Jun 2007 18:12: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 <0JJ400601IG2UC00@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Mon, 04 Jun 2007 12:12:42 -0600 (MDT) Received: from [129.147.9.135] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJ4003IGIL4LD52@mail-amer.sun.com>; Mon, 04 Jun 2007 12:12:41 -0600 (MDT) Date: Mon, 04 Jun 2007 13:12:40 -0500 From: Rich Brown Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <46644A94.1050005@Sun.COM> Sender: Rich.Brown@Sun.COM To: Nicolas.Williams@Sun.COM, psarc-ext@Sun.COM Cc: Joseph Kowalski , "Garrett D'Amore" , Mark.Maybee@Sun.COM, Mark Shellenbaum , Timothy Haley - Sun Microsystem , Christopher.Kirby@Sun.COM, Richard.Morris@Sun.COM, cifs-vfs-team@Sun.COM Message-id: <46645618.8010600@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> <465F2B50.7000404@sun.com> <465F301A.8030502@sun.com> <465F33D0.7090706@sun.com> <20070531210410.GH27420@Sun.COM> <46643C16.8020809@Sun.COM> <46644A94.1050005@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 3440 I just got off the phone with Nico. Turns out we're in violent agreement. I thought he was talking about exposing the system extended attribute files (SUNWattr_rw, SUNWattr_ro). But Nico was talking about the individual attributes (CREATETIME, SYSTEM, HIDDEN, etc., etc.). We've agreed that a future project should add the new attributes to the Solaris client and server as the NFSv4 protocol allows. This is briefly described in section 4.3.1 of the spec for this case. We also agree that the work in described in sectin 4.3.1 is outside the scope of this project. Sorry for the confusion. Thanks. Rich Nicolas.Williams@Sun.COM wrote: > Rich Brown wrote: >> The system attribute files (SUNWattr_rw, SUNWattr_ro) are not intended >> to be used as NFS named attributes directly. The format of these files >> are nvpairs of the system attributes. I wouldn't expect all NFS clients >> and servers to recognize Solaris' nvpair format. > > I would expect a future project to make these attributes visible through > NFSv4 to make each attribute visible as a separate named attribute, not > all of them in one file with nvlist format. But then, perhaps we'd > pursue different extensions to NFSv4 for this anyways. > >> Regarding the registration of named attributes, RFC3530 states: >> "the intent is to promote interoperability where common interest exists". > > But surely also there is a namespace collision avoidance rationale. In > the case of applications there is no problem since presumably two (or > more) different apps using conflicting attribute names wouldn't share > the same files. While in the case of the operating system as the > application we could expect every file to have these attributes, so the > namespace conflict avoidance issue matters. > > I suspect that the NFSv4 WG only intended for imlementors of clients and > servers that rely on special named attributes to register them, whereas > application developers wouldn't have to. Whatever. The WG chose a > method too difficult to use, so we shan't (and if anyone insisted I'd > suggest simply not allowing these SUNW attrs to be visible via NFSv4). > >> But the team is not claiming interoperability with these two attribute >> files. Interoperability would happen with the attributes stored WITHIN >> these attribute files. > > No, the team isn't claiming interop, but folks outside Sun might like to > support these attributes -- I believe that's what the RFC wants us to > facilitate. > >> Registering these attribute files with the IANA means that the project >> team would have to publish an informational RFC to state the name of the >> attributes (SUNWattr_rw and SUNWattr_ro) then describe the syntax and >> semantics of the named attribute contents. Any new attributes added >> to these files would require project teams to submit updates to the RFC. >> As Nico said, this is "a very heavy-weight procedure". >> >> Given that, I don't see the value for Sun in registering the system >> attribute files as named attributes for NFS through the IANA. >> I see it as a high cost for no gain. Not that we think that anyone >> is going to use SUNWattr_* (or whatever we decide on) but the IANA >> registration doesn't even claim to prevent name collisions. > > Really? No NFSv4 client implementor would see any value in > understanding and supporting the use of these attributes? I somehow > doubt that. > > Nico From scott.rotondo@sun.com Mon Jun 4 21:38:08 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 l554c78D019572 for ; Mon, 4 Jun 2007 21:38:07 -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 l554aIHT000432; Tue, 5 Jun 2007 12:36:41 +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 <0JJ500G09BH3WU00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 04 Jun 2007 21:36:39 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ5000JOBH3BB90@nwk-avmta-1.sfbay.Sun.COM>; Mon, 04 Jun 2007 21:36:39 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l554ab8p021233; Mon, 04 Jun 2007 21:36:37 -0700 (PDT) Received: from [10.7.251.213] (punchin-rotondo.SFBay.Sun.COM [10.7.251.213]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l554aZO06308; Mon, 04 Jun 2007 21:36:36 -0700 (PDT) Date: Mon, 04 Jun 2007 22:36:26 -0700 From: Scott Rotondo Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200705301919.l4UJJJKE004851@spidey.central.sun.com> To: Timothy Haley - Sun Microsystem Cc: PSARC-ext@sun.com, Mark.Shellenbaum@sun.com, christopher.kirby@sun.com, cifs-vfs-team@sun.com, mark.maybee@sun.com, richard.morris@sun.com Message-id: <4664F65A.3040709@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 545 > In order to ease the porting of ZFS to BSD and MacOS X the following > "system" attributes will be supported in ZFS. Setting these > attributes requires PRIV_FILE_FLAG_SET. Clearing the attribute > requires a process to have PRIV_FILE_FLAG_CLEAR You're requiring two different privileges, depending on whether the attribute is set or cleared? That's contrary to the way other Solaris privileges work, where a single privilege lets you set a given attribute (say, file permission bits) regardless of the value being set. Scott From scott.rotondo@sun.com Mon Jun 4 21:40:55 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 l554estB019591 for ; Mon, 4 Jun 2007 21:40:55 -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 l554dJ0Z001082; Tue, 5 Jun 2007 12:39: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 <0JJ500M01BLSN000@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Jun 2007 21:39:28 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ500I4IBLR7030@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Jun 2007 21:39:27 -0700 (PDT) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l554dQUQ022352; Mon, 04 Jun 2007 21:39:26 -0700 (PDT) Received: from [10.7.251.213] (punchin-rotondo.SFBay.Sun.COM [10.7.251.213]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l554dPO06331; Mon, 04 Jun 2007 21:39:25 -0700 (PDT) Date: Mon, 04 Jun 2007 22:39:16 -0700 From: Scott Rotondo Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200705301919.l4UJJJKE004851@spidey.central.sun.com> To: Timothy Haley - Sun Microsystem Cc: PSARC-ext@sun.com, Mark.Shellenbaum@sun.com, christopher.kirby@sun.com, cifs-vfs-team@sun.com, mark.maybee@sun.com, richard.morris@sun.com Message-id: <4664F704.5030602@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 987 > > The Solaris CIFS project requires file system support for a number of > "system" and opaque file attributes. For file systems that fully > support CIFS, the system attributes will be present on all file > system objects and the file system will need to update the > attribute(s) as a result of various file system operations such as > data written to a file. The CIFS server and application programs > will also need to be able to query/update the attributes when > needed. Additionally, the CIFS server will be using the Solaris > extended attribute model for storing a number of opaque file > attributes. ZFS will be the primary underlying file system for the > CIFS server. There are certainly other use cases besides CIFS for "system attributes" on files. Does this case establish a protected namespace (e.g. SUNW*) for attributes whose meaning and access control are determined by the system? If not, could the case be expanded to do so? Scott From Nicolas.Williams@sun.com Mon Jun 4 21:49:24 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 l554nOQa019821 for ; Mon, 4 Jun 2007 21:49:24 -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 l554lwxX022627; Mon, 4 Jun 2007 21:47:58 -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 <0JJ500801BZYU800@brm-avmta-1.central.sun.com>; Mon, 04 Jun 2007 22:47:58 -0600 (MDT) Received: from localhost.Central.Sun.COM ([129.153.128.213]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ5005XWBZX5D00@brm-avmta-1.central.sun.com>; Mon, 04 Jun 2007 22:47:57 -0600 (MDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l554l8OF004008; Mon, 04 Jun 2007 23:47:08 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l554l8xv004007; Mon, 04 Jun 2007 23:47:08 -0500 (CDT) Date: Mon, 04 Jun 2007 23:47:08 -0500 From: Nicolas Williams Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <4664F65A.3040709@sun.com> To: Scott Rotondo Cc: Timothy Haley - Sun Microsystem , Mark.Maybee@sun.com, Mark.Shellenbaum@sun.com, PSARC-ext@sun.com, Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <20070605044707.GS2999@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <4664F65A.3040709@sun.com> X-Authentication-warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1688 On Mon, Jun 04, 2007 at 10:36:26PM -0700, Scott Rotondo wrote: > > > In order to ease the porting of ZFS to BSD and MacOS X the following > > "system" attributes will be supported in ZFS. Setting these > > attributes requires PRIV_FILE_FLAG_SET. Clearing the attribute > > requires a process to have PRIV_FILE_FLAG_CLEAR > > You're requiring two different privileges, depending on whether the > attribute is set or cleared? That's contrary to the way other Solaris > privileges work, where a single privilege lets you set a given attribute > (say, file permission bits) regardless of the value being set. I seem to recall a conversation on #onnv about how one could implement the BSD notion of security run levels: make sure that no process remains or can be started with PRIV_FILE_FLAG_CLEAR and IMMUTABLE or APPEND ONLY files truly are, until next boot. Mark enough files IMMUTABLE or APPEND ONLY and drop PRIV_FILE_FLAG_CLEAR early enough at boot and you're set. Now, one thing is that PRIV_FILE_FLAG_CLEAR should be possible to drop and yet one should still be able to perform some operations that currently require all privs (e.g., non-destructive DTrace scripts that use the fbt provider, or mdb -k, but not mdb -kw), just not operations that require all privileges and let the user work around these file attributes. Of course, that may be more difficult to work out than it may at first seem: one would have to be able to mark certain SMF services as IMMUTABLE, but one could not mark the repository that way without causing all SMF services to become IMMUTABLE. But at least having the split privileges now should make it easier to work this out later. Nico -- From Nicolas.Williams@sun.com Mon Jun 4 22:09:35 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 l5559ZWE020345 for ; Mon, 4 Jun 2007 22:09:35 -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 l55582Rt021563; Tue, 5 Jun 2007 06:08:06 +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 <0JJ500D0HCXH1100@brm-avmta-1.central.sun.com>; Mon, 04 Jun 2007 23:08:05 -0600 (MDT) Received: from localhost.Central.Sun.COM ([129.153.128.213]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ500588CXG5A20@brm-avmta-1.central.sun.com>; Mon, 04 Jun 2007 23:08:04 -0600 (MDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5557FXT004061; Tue, 05 Jun 2007 00:07:15 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5557FJq004060; Tue, 05 Jun 2007 00:07:15 -0500 (CDT) Date: Tue, 05 Jun 2007 00:07:15 -0500 From: Nicolas Williams Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <4664F704.5030602@sun.com> To: Scott Rotondo Cc: Timothy Haley - Sun Microsystem , Mark.Maybee@sun.com, Mark.Shellenbaum@sun.com, PSARC-ext@sun.com, Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <20070605050714.GT2999@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <4664F704.5030602@sun.com> X-Authentication-warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1022 On Mon, Jun 04, 2007 at 10:39:16PM -0700, Scott Rotondo wrote: > There are certainly other use cases besides CIFS for "system attributes" > on files. Does this case establish a protected namespace (e.g. SUNW*) > for attributes whose meaning and access control are determined by the > system? If not, could the case be expanded to do so? Rich explained to me that the intent of these SUNW* attrs is to make it possible for existing archivers to backup these new attributes without having to know about the new APIs and without having to represent things like IMMUTABLE as Solaris extended / NFSv4 named attrs. BTW, we need a name for these new things that distinguishes them from Solaris extended / NFSv4 named attrs. And maybe we need to ask why they should be distinguished from them, but whatever -- I'll let a PSARC member (if any cares) tackle that. Given the intended purpose of the SUNW* extended attrs I think this case should set not precedent. OTOH, fsattr(5) already does set such a precedent. Nico -- From lists@mcintyreweb.com Tue Jun 5 00:00:53 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 l5570rCp021973 for ; Tue, 5 Jun 2007 00:00:53 -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 l556xQiJ015044; Mon, 4 Jun 2007 23:59:26 -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 <0JJ500903I32TY00@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Jun 2007 23:59:26 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ500ILYI316Q80@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Jun 2007 23:59:26 -0700 (PDT) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l556GuJr011486; Tue, 05 Jun 2007 06:59:25 +0000 (GMT) Received: from mms04es.sun.com ([150.143.104.74] [150.143.104.74]) by relay2.sun.com with ESMTP id BT-MMP-589975; Tue, 05 Jun 2007 06:59:25 +0000 (Z) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14]) by mms04es.sun.com with ESMTP id BT-MMP-1577594; Tue, 05 Jun 2007 06:59:25 +0000 (Z) Received: from relay44i.sun.com ([192.5.209.118] [192.5.209.118]) by relay1.sun.com with ESMTP id BT-MMP-11966713; Tue, 05 Jun 2007 06:59:25 +0000 (Z) Received: from partslist.i.mcintyreweb.com ([64.166.3.74] [64.166.3.74]) by relay4i.sun.com with ESMTP id BT-MMP-2988522; Tue, 05 Jun 2007 06:59:24 +0000 (Z) Received: from [127.0.0.1] (localhost [127.0.0.1]) by partslist.i.mcintyreweb.com (8.13.8+Sun/8.13.8) with ESMTP id l556xEDY012241; Mon, 04 Jun 2007 23:59:18 -0700 (PDT) Date: Mon, 04 Jun 2007 23:59:14 -0700 From: Hugh McIntyre Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <46645618.8010600@Sun.COM> To: Rich Brown Cc: Nicolas.Williams@sun.com, psarc-ext@sun.com, Mark.Maybee@sun.com, Mark Shellenbaum , Timothy Haley - Sun Microsystem , Joseph Kowalski , Christopher.Kirby@sun.com, Richard.Morris@sun.com, "Garrett D'Amore" , cifs-vfs-team@sun.com Message-id: <466509C2.80505@mcintyreweb.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> <465EF712.6050304@Sun.COM> <465F2B50.7000404@sun.com> <465F301A.8030502@sun.com> <465F33D0.7090706@sun.com> <20070531210410.GH27420@Sun.COM> <46643C16.8020809@Sun.COM> <46644A94.1050005@Sun.COM> <46645618.8010600@Sun.COM> User-Agent: Thunderbird 1.5.0.10 (X11/20070303) Status: RO Content-Length: 1114 Rich Brown wrote: > I just got off the phone with Nico. Turns out we're in violent agreement. > > I thought he was talking about exposing the system extended attribute files > (SUNWattr_rw, SUNWattr_ro). But Nico was talking about the individual > attributes (CREATETIME, SYSTEM, HIDDEN, etc., etc.). There's a good chance I've not been paying attention to all of the details here, in which case I apologize. (And the original 1-pager appears to be non-public, which does not help). But, what happens if someone tries to create an extended attribute with one of these reserved names (such as HIDDEN) via the existing interfaces in fsattr(5)? Or tries to read the value of SYSTEM via fsattr(5) after NFSv4 sets it via SUNWattr_*? What happens if someone upgrades an existing system with attributes with these reserved names -- does this mean you'll possibly have duplicates with conflicting values? Granted, it's probably unlikely that anyone is actually doing this, so maybe the question is not a high priority. But if not, this is a similar question to the one Nico just asked, I think. Hugh. From casper@holland.sun.com Tue Jun 5 01:28:01 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 l558RxjT023574 for ; Tue, 5 Jun 2007 01:28:00 -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 l558QNJd029359; Tue, 5 Jun 2007 16:26:27 +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 <0JJ500K0FM40AF00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Jun 2007 01:26:24 -0700 (PDT) Received: from sr1-eaft06-01.holland.sun.com ([129.159.237.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ5002T2M3XYCA0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Jun 2007 01:26:22 -0700 (PDT) Received: from holland (room101 [129.159.130.93]) by sr1-eaft06-01.holland.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l558QKhE019780; Tue, 05 Jun 2007 10:26:20 +0200 (MEST) Date: Tue, 05 Jun 2007 10:26:20 +0200 From: Casper.Dik@sun.com Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <20070605044707.GS2999@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Scott Rotondo , Timothy Haley - Sun Microsystem , Mark.Maybee@sun.com, Mark.Shellenbaum@sun.com, PSARC-ext@sun.com, Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <200706050826.l558QKhE019780@sr1-eaft06-01.holland.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <4664F65A.3040709@sun.com> <20070605044707.GS2999@Sun.COM> Status: RO Content-Length: 2588 >On Mon, Jun 04, 2007 at 10:36:26PM -0700, Scott Rotondo wrote: >> >> > In order to ease the porting of ZFS to BSD and MacOS X the following >> > "system" attributes will be supported in ZFS. Setting these >> > attributes requires PRIV_FILE_FLAG_SET. Clearing the attribute >> > requires a process to have PRIV_FILE_FLAG_CLEAR >> >> You're requiring two different privileges, depending on whether the >> attribute is set or cleared? That's contrary to the way other Solaris >> privileges work, where a single privilege lets you set a given attribute >> (say, file permission bits) regardless of the value being set. > >I seem to recall a conversation on #onnv about how one could implement >the BSD notion of security run levels: make sure that no process remains >or can be started with PRIV_FILE_FLAG_CLEAR and IMMUTABLE or APPEND ONLY >files truly are, until next boot. Mark enough files IMMUTABLE or APPEND >ONLY and drop PRIV_FILE_FLAG_CLEAR early enough at boot and you're set. We should not implement a BSD notion of secure levels based on a single privilege. That is BROKEN beyond believe. A single privilege must not be allowed to side step the main protection mechanism. If the flags should not be clearable, which is something I can understand, then you should require ALL privileges (available in the current zone) >Now, one thing is that PRIV_FILE_FLAG_CLEAR should be possible to drop >and yet one should still be able to perform some operations that >currently require all privs (e.g., non-destructive DTrace scripts that >use the fbt provider, or mdb -k, but not mdb -kw), just not operations >that require all privileges and let the user work around these file >attributes. The fbt provider does not require all privileges neither does mdb -k. We already have secure levels; but they are per-process and they are called the limit set. >Of course, that may be more difficult to work out than it may at first >seem: one would have to be able to mark certain SMF services as >IMMUTABLE, but one could not mark the repository that way without >causing all SMF services to become IMMUTABLE. But at least having the >split privileges now should make it easier to work this out later. Considering the amount of destruction possible by allowing files to be marked immutable incorrectly, I think we need to do some serious thinking on this matter. There is a reason why Solaris privileges require all privileges for certain operations: it's because those operations are allow sidestepping the security levels; it's our form of "secure-levels". Casper From casper@holland.sun.com Tue Jun 5 01:31:31 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 l558VUuv023593 for ; Tue, 5 Jun 2007 01:31:30 -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 l558TtFc000088; Tue, 5 Jun 2007 16:29:58 +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 <0JJ500K03M9WN900@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Jun 2007 01:29:56 -0700 (PDT) Received: from sr1-eaft06-01.holland.sun.com ([129.159.237.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ5002D3M9VYRB0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Jun 2007 01:29:56 -0700 (PDT) Received: from holland (room101 [129.159.130.93]) by sr1-eaft06-01.holland.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l558Ts01022208; Tue, 05 Jun 2007 10:29:54 +0200 (MEST) Date: Tue, 05 Jun 2007 10:29:54 +0200 From: Casper.Dik@sun.com Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <20070605050714.GT2999@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Scott Rotondo , Timothy Haley - Sun Microsystem , Mark.Maybee@sun.com, Mark.Shellenbaum@sun.com, PSARC-ext@sun.com, Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <200706050829.l558Ts01022208@sr1-eaft06-01.holland.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <4664F704.5030602@sun.com> <20070605050714.GT2999@Sun.COM> Status: RO Content-Length: 1080 >On Mon, Jun 04, 2007 at 10:39:16PM -0700, Scott Rotondo wrote: >> There are certainly other use cases besides CIFS for "system attributes" >> on files. Does this case establish a protected namespace (e.g. SUNW*) >> for attributes whose meaning and access control are determined by the >> system? If not, could the case be expanded to do so? > >Rich explained to me that the intent of these SUNW* attrs is to make it >possible for existing archivers to backup these new attributes without >having to know about the new APIs and without having to represent >things like IMMUTABLE as Solaris extended / NFSv4 named attrs. How does the project team intend to solve the fact that such attributes have no meaning to other implementations and that restrictions which need to be applied on modification of such attributes in the context of Solaris are also enforced in other environments? Suppose I have a filer of type X; I've added a SUNW_IMMUTABLE attribute from Solaris to a file from a Solaris client. What is stopping a Windows client from removing that attribute? Casper From Nicolas.Williams@sun.com Tue Jun 5 01:55:32 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 l558tWvR024014 for ; Tue, 5 Jun 2007 01:55:32 -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 l558s2xK000884; Tue, 5 Jun 2007 01:54:04 -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 <0JJ500N0LNE34500@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Jun 2007 01:54:03 -0700 (PDT) Received: from localhost.Central.Sun.COM ([129.153.128.213]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ50028ENE2YPC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Jun 2007 01:54:02 -0700 (PDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l558rE4C005154; Tue, 05 Jun 2007 03:53:14 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l558rEQW005153; Tue, 05 Jun 2007 03:53:14 -0500 (CDT) Date: Tue, 05 Jun 2007 03:53:13 -0500 From: Nicolas Williams Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200706050826.l558QKhE019780@sr1-eaft06-01.holland.sun.com> To: Casper.Dik@sun.com Cc: Scott Rotondo , Timothy Haley - Sun Microsystem , Mark.Maybee@sun.com, Mark.Shellenbaum@sun.com, PSARC-ext@sun.com, Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <20070605085313.GZ2999@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <4664F65A.3040709@sun.com> <20070605044707.GS2999@Sun.COM> <200706050826.l558QKhE019780@sr1-eaft06-01.holland.sun.com> X-Authentication-warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2995 On Tue, Jun 05, 2007 at 10:26:20AM +0200, Casper.Dik@Sun.COM wrote: > >On Mon, Jun 04, 2007 at 10:36:26PM -0700, Scott Rotondo wrote: > >> > >> > In order to ease the porting of ZFS to BSD and MacOS X the following > >> > "system" attributes will be supported in ZFS. Setting these > >> > attributes requires PRIV_FILE_FLAG_SET. Clearing the attribute > >> > requires a process to have PRIV_FILE_FLAG_CLEAR > >> > >> You're requiring two different privileges, depending on whether the > >> attribute is set or cleared? That's contrary to the way other Solaris > >> privileges work, where a single privilege lets you set a given attribute > >> (say, file permission bits) regardless of the value being set. > > > >I seem to recall a conversation on #onnv about how one could implement > >the BSD notion of security run levels: make sure that no process remains > >or can be started with PRIV_FILE_FLAG_CLEAR and IMMUTABLE or APPEND ONLY > >files truly are, until next boot. Mark enough files IMMUTABLE or APPEND > >ONLY and drop PRIV_FILE_FLAG_CLEAR early enough at boot and you're set. > > We should not implement a BSD notion of secure levels based on a single > privilege. > > That is BROKEN beyond believe. > > A single privilege must not be allowed to side step the main protection > mechanism. > > If the flags should not be clearable, which is something I can understand, > then you should require ALL privileges (available in the current zone) Ah, ALL privs instead of a special priv to clear, make sense, but see below. > Considering the amount of destruction possible by allowing files to be > marked immutable incorrectly, I think we need to do some serious thinking > on this matter. > > There is a reason why Solaris privileges require all privileges for > certain operations: it's because those operations are allow sidestepping > the security levels; it's our form of "secure-levels". But what we don't provide that BSD run-levels do, is an administrative way to make sure that the system has entered such a "secure run-level." In Solaris that would be done by making sure that no process has (and therefore can't get) some privilege in its L/P/E sets, no? But we don't have an SMF service, say, that we could enable, that would allow this. Now, suppose that we had such a service. Then we could have a system running without any process with PRIV_FILE_FLAG_SET in any priv set, but now operations that normally need all privs cannot be done, and if the intent in dropping PRIV_FILE_FLAG_SET was only to make sure that certain files were immutable until the next boot then dropping that priv will have accomplished more than that. I'm thinking of writing to files owned by UID 0, which requires all privs, not just PRIV_FILE_DAC_WRITE. OTOH, perhaps that should be the intent in dropping PRIV_FILE_FLAG_SET: to prevent not just writes to immutable files and so on but also to prevent all operations which would require the caller have all privs. Nico -- From casper@holland.sun.com Tue Jun 5 02:19:51 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 l559Jl61024270 for ; Tue, 5 Jun 2007 02:19:51 -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 l559H4Qt004748; Tue, 5 Jun 2007 02:17:06 -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 <0JJ50080ROGHWJ00@brm-avmta-1.central.sun.com>; Tue, 05 Jun 2007 03:17:05 -0600 (MDT) Received: from sr1-eaft06-01.holland.sun.com ([129.159.237.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ50052EOGG5BC0@brm-avmta-1.central.sun.com>; Tue, 05 Jun 2007 03:17:04 -0600 (MDT) Received: from holland (room101 [129.159.130.93]) by sr1-eaft06-01.holland.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l559H1E3060856; Tue, 05 Jun 2007 11:17:02 +0200 (MEST) Date: Tue, 05 Jun 2007 11:17:01 +0200 From: Casper.Dik@Sun.COM Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <20070605085313.GZ2999@Sun.COM> Sender: casper@holland.sun.com To: Nicolas Williams Cc: Scott Rotondo , Timothy Haley - Sun Microsystem , Mark.Maybee@Sun.COM, Mark.Shellenbaum@Sun.COM, PSARC-ext@Sun.COM, Christopher.Kirby@Sun.COM, Richard.Morris@Sun.COM, cifs-vfs-team@Sun.COM Message-id: <200706050917.l559H1E3060856@sr1-eaft06-01.holland.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <4664F65A.3040709@sun.com> <20070605044707.GS2999@Sun.COM> <200706050826.l558QKhE019780@sr1-eaft06-01.holland.sun.com> <20070605085313.GZ2999@Sun.COM> Status: RO Content-Length: 2667 >But what we don't provide that BSD run-levels do, is an administrative >way to make sure that the system has entered such a "secure run-level." >In Solaris that would be done by making sure that no process has (and >therefore can't get) some privilege in its L/P/E sets, no? But we don't >have an SMF service, say, that we could enable, that would allow this. I'm aware of that; but BSD secure-levels have many shortcomings that make it impossible to retrofit this to Solaris, except if we limit it to a tiny subset of buttoned down appliances. But we can provide secure-levels on the per-process basis and continue to have Solaris work; with "work" meaning the ability to add devices, disks, device drivers, live-upgrade, create zpools, etc. All you need to do is prevent users from entering the system with an unrestrictive limit set; the OS itself and the core components will need to continue to be able to modify essentially all of the OS if we want to have any form of "dynamic OS". I don't see that as a problem. I see secure-levels as a useful hack, but believe that the boundary of protection should not be the kernel; it should be the kernel and the associated processes such as SMF, FMA, DR, etc. >Now, suppose that we had such a service. Then we could have a system >running without any process with PRIV_FILE_FLAG_SET in any priv set, but >now operations that normally need all privs cannot be done, and if the >intent in dropping PRIV_FILE_FLAG_SET was only to make sure that certain >files were immutable until the next boot then dropping that priv will >have accomplished more than that. I'm thinking of writing to files >owned by UID 0, which requires all privs, not just PRIV_FILE_DAC_WRITE. > >OTOH, perhaps that should be the intent in dropping PRIV_FILE_FLAG_SET: >to prevent not just writes to immutable files and so on but also to >prevent all operations which would require the caller have all privs. But unfortunately it would prevent all such operations which may not be what you want. Before I want to see these privileges for immutable files I want to know more about what we are going to do with this and what our direction with this is. For now, the primary use of immutable files is the fact that they allow you to mark files as "special" and that you cannot overwrite or remove them by accident (do we disallow removal for immutable files?) To this end I think just a "set" privilege and requiring "ALL" to remove them. For the remainder, the whole picture should include a discussion about signed files (which should have immutability as a property if you ask me), secure execution and hardened operation. Casper From Mark.Shellenbaum@sun.com Tue Jun 5 09:07: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 l55G7k47001335 for ; Tue, 5 Jun 2007 09:07:46 -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 l55G5nQX023006; Tue, 5 Jun 2007 17:06:18 +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 <0JJ600H0R7EHR600@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Jun 2007 09:06:17 -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 <0JJ600DJJ7EH1Y30@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Jun 2007 09:06:17 -0700 (PDT) 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 l55G6HdC003797; Tue, 05 Jun 2007 16:06:17 +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 <0JJ60090176O6J00@mail-amer.sun.com> (original mail from Mark.Shellenbaum@Sun.COM); Tue, 05 Jun 2007 10:06:17 -0600 (MDT) Received: from [172.20.25.34] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJ6003XZ7EFNCQ5@mail-amer.sun.com>; Tue, 05 Jun 2007 10:06:16 -0600 (MDT) Date: Tue, 05 Jun 2007 10:06:15 -0600 From: Mark Shellenbaum Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200706050917.l559H1E3060856@sr1-eaft06-01.holland.sun.com> Sender: Mark.Shellenbaum@sun.com To: Casper.Dik@sun.com Cc: Nicolas Williams , Scott Rotondo , Timothy Haley - Sun Microsystem , Mark.Maybee@sun.com, PSARC-ext@sun.com, Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <466589F7.8050306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <4664F65A.3040709@sun.com> <20070605044707.GS2999@Sun.COM> <200706050826.l558QKhE019780@sr1-eaft06-01.holland.sun.com> <20070605085313.GZ2999@Sun.COM> <200706050917.l559H1E3060856@sr1-eaft06-01.holland.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 5029 Casper.Dik@Sun.COM wrote: > >> But what we don't provide that BSD run-levels do, is an administrative >> way to make sure that the system has entered such a "secure run-level." >> In Solaris that would be done by making sure that no process has (and >> therefore can't get) some privilege in its L/P/E sets, no? But we don't >> have an SMF service, say, that we could enable, that would allow this. > > I'm aware of that; but BSD secure-levels have many shortcomings that > make it impossible to retrofit this to Solaris, except if we limit > it to a tiny subset of buttoned down appliances. > > But we can provide secure-levels on the per-process basis and continue > to have Solaris work; with "work" meaning the ability to add devices, > disks, device drivers, live-upgrade, create zpools, etc. > > All you need to do is prevent users from entering the system with an > unrestrictive limit set; the OS itself and the core components will > need to continue to be able to modify essentially all of the OS if > we want to have any form of "dynamic OS". > > I don't see that as a problem. I see secure-levels as a useful hack, > but believe that the boundary of protection should not be the kernel; > it should be the kernel and the associated processes such as SMF, FMA, > DR, etc. > >> Now, suppose that we had such a service. Then we could have a system >> running without any process with PRIV_FILE_FLAG_SET in any priv set, but >> now operations that normally need all privs cannot be done, and if the >> intent in dropping PRIV_FILE_FLAG_SET was only to make sure that certain >> files were immutable until the next boot then dropping that priv will >> have accomplished more than that. I'm thinking of writing to files >> owned by UID 0, which requires all privs, not just PRIV_FILE_DAC_WRITE. >> >> OTOH, perhaps that should be the intent in dropping PRIV_FILE_FLAG_SET: >> to prevent not just writes to immutable files and so on but also to >> prevent all operations which would require the caller have all privs. > > But unfortunately it would prevent all such operations which may not > be what you want. > > Before I want to see these privileges for immutable files I want to > know more about what we are going to do with this and what our direction > with this is. > > For now, the primary use of immutable files is the fact that they allow > you to mark files as "special" and that you cannot overwrite or remove > them by accident (do we disallow removal for immutable files?) > > To this end I think just a "set" privilege and requiring "ALL" to remove > them. > > For the remainder, the whole picture should include a discussion about > signed files (which should have immutability as a property if you ask me), > secure execution and hardened operation. > > > Casper > Combining the responses from the recent questions: Privileges (Scott Rotondo, Casper Dik): The project team is willing to remove the PRIV_FILE_FLAG_CLEAR privilege and require a process to have "all" privileges in order to clear attributes such as immutable. Uses of system attributes other than CIFS (Scott Rotondo): There are certainly other uses for system attributes such as virus scanning, HSM applications, etc. The CIFS server is called out because it is the first project requiring system attributes in Solaris. Protected namespace (Scott Rotondo, Nico Williams): The SUNW* convention is documented in fsattr(5). Creating attribute files with system attribute names (Hugh McIntyre): A user is free to create whatever extended attribute file s/he wants but that doesn't mean that Solaris will recognize it as a system attribute. As stated in section 4.1 of the spec: Instead of exposing each individual system attribute as a named object, we are exposing named sets of system attributes as views into the system attribute space. This is being done to minimize clutter in the name space. Manipulating attributes in a non-Solaris environment (Casper Dik): The system attributes do not exist in separate attribute files (such as SUNW_IMMUTABLE). The individual system attributes are represented as nvpairs within SUNWattr_rw and SUNWattr_ro. See section 4.1 for further details. The CIFS client/server only knows about the DOS level attributes. Attributes such as immutable are not part of the SMB protocol. If a CIFS client attempts to update an immutable attribute in SUNWattr_rw attribute file then that process would need the appropriate privileges in the cred created by the CIFS server to manipulate those attributes. See the last paragraph of section 4.1 and all of section 4.3.1 for more on NFS support. Removal of "immutable" files (Casper Dik): A file marked as "immutable" cannot be removed. Signed files (Casper Dik): Signed files are not part of this case. We are laying the foundation for future projects to take advantage of these attributes. -Mark From sommerfeld@sun.com Tue Jun 5 13:11:36 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 l55KBaZB012023 for ; Tue, 5 Jun 2007 13:11:36 -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 l55K9mKe016127; Tue, 5 Jun 2007 14:09:50 -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 <0JJ600M0HIOXPS00@nwk-avmta-2.sfbay.sun.com>; Tue, 05 Jun 2007 13:10:09 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ600BAJIOWP2D0@nwk-avmta-2.sfbay.sun.com>; Tue, 05 Jun 2007 13:10:09 -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 l55KA59N009567; Tue, 05 Jun 2007 16:10:05 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l55KA5bd020765; Tue, 05 Jun 2007 16:10:05 -0400 (EDT) Date: Tue, 05 Jun 2007 16:10:04 -0400 From: Bill Sommerfeld Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <4664F65A.3040709@sun.com> To: Scott Rotondo Cc: Timothy Haley - Sun Microsystem , mark.maybee@sun.com, Mark.Shellenbaum@sun.com, PSARC-ext@sun.com, christopher.kirby@sun.com, richard.morris@sun.com, cifs-vfs-team@sun.com Message-id: <1181074204.20679.9.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <4664F65A.3040709@sun.com> Status: RO Content-Length: 1008 On Mon, 2007-06-04 at 22:36 -0700, Scott Rotondo wrote: > > In order to ease the porting of ZFS to BSD and MacOS X the following > > "system" attributes will be supported in ZFS. Setting these > > attributes requires PRIV_FILE_FLAG_SET. Clearing the attribute > > requires a process to have PRIV_FILE_FLAG_CLEAR > > You're requiring two different privileges, depending on whether the > attribute is set or cleared? That's contrary to the way other Solaris > privileges work, where a single privilege lets you set a given attribute > (say, file permission bits) regardless of the value being set. The BSD version of the interface severely constrains when and how "system" append-only and immutable bits may be cleared (essentially, only in single-user mode). I think that separating "set" and "clear" has utility from a least-privilege standpoint in that it allows a process to be able to create an append-only log file without being able to tamper with existing log entries. - Bill From Alan.M.Wright@sun.com Tue Jun 5 23:37: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 l566bcjt024942 for ; Tue, 5 Jun 2007 23:37:39 -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 l566ZrPG002478; Wed, 6 Jun 2007 14:36:09 +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 <0JJ700303BO6WM00@nwk-avmta-2.sfbay.sun.com>; Tue, 05 Jun 2007 23:36:06 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ700MUJBO6CM50@nwk-avmta-2.sfbay.sun.com>; Tue, 05 Jun 2007 23:36:06 -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 l566a5pO026798; Wed, 06 Jun 2007 06:36:05 +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 <0JJ700E01ALWUF00@mail-amer.sun.com> (original mail from Alan.M.Wright@Sun.COM); Wed, 06 Jun 2007 00:36:05 -0600 (MDT) Received: from amw2000 ([10.1.98.32]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJ700DHYBO4ES35@mail-amer.sun.com>; Wed, 06 Jun 2007 00:36:05 -0600 (MDT) Date: Tue, 05 Jun 2007 23:32:03 -0700 From: Alan Wright Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] Sender: Alan.M.Wright@sun.com To: Casper.Dik@sun.com, Nicolas Williams Cc: Scott Rotondo , Timothy Haley - Sun Microsystem , Mark.Maybee@sun.com, Mark.Shellenbaum@sun.com, PSARC-ext@sun.com, Christopher.Kirby@sun.com, Richard.Morris@sun.com, cifs-vfs-team@sun.com Message-id: <050c01c7a804$659e57c0$2062010a@amw2000> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Mailer: Microsoft Outlook Express 6.00.2800.1478 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <4664F704.5030602@sun.com> <20070605050714.GT2999@Sun.COM> <200706050829.l558Ts01022208@sr1-eaft06-01.holland.sun.com> Status: RO Content-Length: 264 Casper.Dik wrote: > Suppose I have a filer of type X; I've added a SUNW_IMMUTABLE attribute > from Solaris to a file from a Solaris client. What is stopping a Windows > client from removing that attribute? The immutable attribute isn't visible over CIFS. Alan From glenn.skinner@sun.com Wed Jun 6 09:48:22 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 l56GmMBY010469 for ; Wed, 6 Jun 2007 09:48:22 -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 l56GkugR000104; Wed, 6 Jun 2007 09:46:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJ8003093Y73400@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Jun 2007 09:46:55 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ800M3V3Y6IF70@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Jun 2007 09:46:54 -0700 (PDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l56GkrpD003122; Wed, 06 Jun 2007 09:46:53 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id l56Ghw23002756; Wed, 06 Jun 2007 09:43:58 -0700 (PDT) Date: Wed, 06 Jun 2007 09:43:58 -0700 (PDT) From: Glenn Skinner Subject: Re: 2007/315 [Extensible Attribute Interfaces] To: PSARC-ext@sun.com, timh@spidey.central.sun.com Cc: Mark.Shellenbaum@sun.com, christopher.kirby@sun.com, cifs-vfs-team@sun.com, mark.maybee@sun.com, richard.morris@sun.com Reply-to: Glenn Skinner Message-id: <200706061643.l56Ghw23002756@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 85SLqOWwHw19IloJlpesCQ== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 595 Date: Wed, 30 May 2007 13:19:19 -0600 (MDT) From: Timothy Haley - Sun Microsystem Subject: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] ... 2.0 OVERVIEW The Solaris CIFS project requires file system support for a number of "system" and opaque file attributes. Suppose someone desires to add a new "system" attribute. By what criteria can we (the ARC) judge whether that attribute qualifies as being a "system" attribute? That is, what constitutes "systemness" in an attribute? -- Glenn From Rich.Brown@sun.com Wed Jun 6 10:04:15 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 l56H4Fba012252 for ; Wed, 6 Jun 2007 10:04:15 -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 l56H2jcN003785; Wed, 6 Jun 2007 10:02: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 <0JJ8006274OO6O00@brm-avmta-1.central.sun.com>; Wed, 06 Jun 2007 11:02:48 -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 <0JJ800IQQ4OLG1E0@brm-avmta-1.central.sun.com>; Wed, 06 Jun 2007 11:02:45 -0600 (MDT) Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l56H2jud028852; Wed, 06 Jun 2007 17:02:45 +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 <0JJ800A014NZ3300@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Wed, 06 Jun 2007 11:02:45 -0600 (MDT) Received: from [129.147.9.135] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJ8001TQ4OKQF21@mail-amer.sun.com>; Wed, 06 Jun 2007 11:02:45 -0600 (MDT) Date: Wed, 06 Jun 2007 12:02:44 -0500 From: Rich Brown Subject: Re: 2007/315 [Extensible Attribute Interfaces] In-reply-to: <200706061643.l56Ghw23002756@ivrel.sfbay.sun.com> Sender: Rich.Brown@sun.com To: Glenn Skinner Cc: PSARC-ext@sun.com, Tim Haley , Mark.Shellenbaum@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <4666E8B4.1000107@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: <200706061643.l56Ghw23002756@ivrel.sfbay.sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 820 Glenn Skinner wrote: > Date: Wed, 30 May 2007 13:19:19 -0600 (MDT) > From: Timothy Haley - Sun Microsystem > Subject: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack > timeout 06/06/2007] > > ... > 2.0 OVERVIEW > > The Solaris CIFS project requires file system support for a > number of "system" and opaque file attributes. > > Suppose someone desires to add a new "system" attribute. By what > criteria can we (the ARC) judge whether that attribute qualifies as > being a "system" attribute? That is, what constitutes "systemness" in > an attribute? > > -- Glenn > I believe that if an operating system module needs to use the value of an attribute to make a decision, then that attribute is considered a system attribute. Rich From glenn.skinner@sun.com Wed Jun 6 12:21:54 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 l56JLsMb019108 for ; Wed, 6 Jun 2007 12:21:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l56JKNAk004730; Wed, 6 Jun 2007 12:20:29 -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 <0JJ800F09B24JK00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 Jun 2007 12:20:28 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ800C5MB248S90@nwk-avmta-2.sfbay.sun.com>; Wed, 06 Jun 2007 12:20:28 -0700 (PDT) Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l56JKRbs005491; Wed, 06 Jun 2007 12:20:27 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id l56JHW5M002891; Wed, 06 Jun 2007 12:17:32 -0700 (PDT) Date: Wed, 06 Jun 2007 12:17:32 -0700 (PDT) From: Glenn Skinner Subject: Re: 2007/315 [Extensible Attribute Interfaces] To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, tim.haley@sun.com, Mark.Shellenbaum@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Reply-to: Glenn Skinner Message-id: <200706061917.l56JHW5M002891@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: Da27P8IL4CEugDwp8W25Pg== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2068 Date: Wed, 06 Jun 2007 12:02:44 -0500 From: Rich Brown Subject: Re: 2007/315 [Extensible Attribute Interfaces] Glenn Skinner wrote: > > Suppose someone desires to add a new "system" attribute. By what > criteria can we (the ARC) judge whether that attribute qualifies > as being a "system" attribute? That is, what constitutes > "systemness" in an attribute? I believe that if an operating system module needs to use the value of an attribute to make a decision, then that attribute is considered a system attribute. Let's probe this characterization a bit. At first glance, this just seems to move the question to what constitutes an operating system module. Does this mean somethng that's part of the kernel's address space? Or (as was suggested during today's PSARC meeting) does this mean something that's part of the trusted computing base? Consider, for example, a third party HSM that wants to maintain an attribute that records an offset beyond which the file's data is staged out to tertiary storage. Is this a system attribute? Depending on how the HSM is implemented it may or may not be interpreted by code residing in the kernel address space. The HSM will almost certainly require some level of elevated privilege to operate successfully. Does that push it into the trusted computing base? If we decide the attribute does qualify as a system attribute, would or should the HSM vendor need to get ARC approval for the attribute name and to have it live alongside the other system attributes? Questions like these make me uneasy about introducing a potentially open ended set of "system" attributes. The ones proposed as part of this case all seem (more or less) reasonable. But the case also outlines a scheme for extensibility. I would like the bounds for what qualifies for inclusion to be as clear as possible. (And for extra credit, I would like that hypothetical third party HSM vendor to be able to deliver product without having to visit PSARC.) -- Glenn From gww@eng.sun.com Wed Jun 6 17:59:19 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 l570xIvQ029310 for ; Wed, 6 Jun 2007 17:59:18 -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 l570vpdD002147; Thu, 7 Jun 2007 01:57:52 +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 <0JJ800G07QOED100@brm-avmta-1.central.sun.com>; Wed, 06 Jun 2007 18:57:50 -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 <0JJ800ECUQODG810@brm-avmta-1.central.sun.com>; Wed, 06 Jun 2007 18:57:50 -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 l570vmpJ026224; Wed, 06 Jun 2007 17:57:48 -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 l5710EqF005093; Wed, 06 Jun 2007 18:00:14 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5710Eec005092; Wed, 06 Jun 2007 18:00:14 -0700 (PDT) Date: Wed, 06 Jun 2007 18:00:14 -0700 (PDT) From: Gary Winiger Subject: Re: 2007/315 [Extensible Attribute Interfaces] To: Rich.Brown@Sun.COM, glenn.skinner@Sun.COM Cc: Christopher.Kirby@Sun.COM, Mark.Maybee@Sun.COM, Mark.Shellenbaum@Sun.COM, PSARC-ext@Sun.COM, Richard.Morris@Sun.COM, cifs-vfs-team@Sun.COM, tim.haley@Sun.COM Message-id: <200706070100.l5710Eec005092@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1372 I'm slowly getting caught up here. From my first reading, I have two nits: The spec says micro binding. CIFS server I suspect in minor. I don't believe there is any micro release planned. I can see this project being useful before S11, perhaps a patch binding is appropriate. The man page says "Evolving" that should be "Committed". Now some real questions: Perhaps there's overlap with Glenn's line. Perhaps this has been answered. As I asked in the meeting today, a summary of the spec changes would. How is the Sun/Solaris distro name space managed? I can see once zfs is bootable wanting to add various "system" attributes. How will collisions be avoided with other possible distros? Can each attribute have a separate policy? For example, I may wish to associate privileges with executables or file signatures with each system data file. To view the privileges or signature may not require any policy (beyond the default). However, to modify should likely require some special policy. Is there some thought that "system" attributes are ones that require some policy either to view or modify? Perhaps defining what does NOT constitute a "system" attribute would be helpful. One might say that other distros could use the XXX_ro / XXX_rw name space. I'm planning to go back over the materials and discussion again. Thankx, Gary.. From Rich.Brown@sun.com Thu Jun 7 07:38:42 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 l57Ecfjq014562 for ; Thu, 7 Jun 2007 07:38:42 -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 l57EaufZ029819; Thu, 7 Jun 2007 15:37:14 +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 <0JJ900105SM0NR00@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Jun 2007 07:37:12 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJ900IDUSLZD680@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Jun 2007 07:37:12 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l57EbB9m012303; Thu, 07 Jun 2007 14:37: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 <0JJ900N01S5M0100@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Thu, 07 Jun 2007 08:37:11 -0600 (MDT) Received: from [129.147.9.135] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJ900I0USLXT7P6@mail-amer.sun.com>; Thu, 07 Jun 2007 08:37:10 -0600 (MDT) Date: Thu, 07 Jun 2007 09:37:08 -0500 From: Rich Brown Subject: Re: 2007/315 [Extensible Attribute Interfaces] In-reply-to: <4666E8B4.1000107@Sun.COM> Sender: Rich.Brown@sun.com To: PSARC-ext@sun.com Cc: Tim Haley , Mark.Shellenbaum@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <46681814.2000908@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: <200706061643.l56Ghw23002756@ivrel.sfbay.sun.com> <4666E8B4.1000107@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 932 At the PSARC meeting, the project team was asked to summarize the changes in the spec since it was sent out on 30 May. I volunteered to provide this. (I have not included a summary of the discussions which resulted in no change to the spec.) - The team agreed that the NODUMP attribute could be set on Solaris. However, RFEs would need to be opened for the various archivers to pay attention to the attribute. - Spencer informed the team that the SYSTEM attribute is also one of the NFSv4 recommended attributes (along with ARCHIVE and HIDDEN). I also found that CREATETIME (time_create) is also one of the recommended attributes. This will updated in section 4.3.1 of the spec. - The project team has agreed to remove the PRIV_FILE_FLAG_CLEAR privilege and require a process to have "all" privileges in order to clear the attributes listed in sections 3.2, 3.4, plus NODUMP from section 3.3. From Rich.Brown@sun.com Thu Jun 7 11:42:11 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 l57IgAh5019439 for ; Thu, 7 Jun 2007 11:42:11 -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 l57IeZXY024707; Fri, 8 Jun 2007 02:40:41 +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 <0JJA00C0D3VS5N00@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Jun 2007 11:40:40 -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 <0JJA009EJ3VSEP40@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Jun 2007 11:40:40 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l57IedAX023806; Thu, 07 Jun 2007 18:40:39 +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 <0JJA004013O51500@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Thu, 07 Jun 2007 12:40:39 -0600 (MDT) Received: from [129.147.9.135] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJA0098M3VQ6SU3@mail-amer.sun.com>; Thu, 07 Jun 2007 12:40:39 -0600 (MDT) Date: Thu, 07 Jun 2007 13:40:38 -0500 From: Rich Brown Subject: Re: 2007/315 [Extensible Attribute Interfaces] In-reply-to: <200706061917.l56JHW5M002891@ivrel.sfbay.sun.com> Sender: Rich.Brown@sun.com To: Glenn Skinner Cc: PSARC-ext@sun.com, Tim.Haley@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <46685126.10907@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: <200706061917.l56JHW5M002891@ivrel.sfbay.sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 4828 Glenn Skinner wrote: > Date: Wed, 06 Jun 2007 12:02:44 -0500 > From: Rich Brown > Subject: Re: 2007/315 [Extensible Attribute Interfaces] > > Glenn Skinner wrote: > > > > Suppose someone desires to add a new "system" attribute. By what > > criteria can we (the ARC) judge whether that attribute qualifies > > as being a "system" attribute? That is, what constitutes > > "systemness" in an attribute? > > I believe that if an operating system module needs to use the value > of an attribute to make a decision, then that attribute is > considered a system attribute. > > Let's probe this characterization a bit. > > At first glance, this just seems to move the question to what > constitutes an operating system module. Does this mean somethng that's > part of the kernel's address space? Or (as was suggested during > today's PSARC meeting) does this mean something that's part of the > trusted computing base? > > Consider, for example, a third party HSM that wants to maintain an > attribute that records an offset beyond which the file's data is staged > out to tertiary storage. Is this a system attribute? Depending on how > the HSM is implemented it may or may not be interpreted by code > residing in the kernel address space. The HSM will almost certainly > require some level of elevated privilege to operate successfully. Does > that push it into the trusted computing base? If we decide the > attribute does qualify as a system attribute, would or should the HSM > vendor need to get ARC approval for the attribute name and to have it > live alongside the other system attributes? > > Questions like these make me uneasy about introducing a potentially > open ended set of "system" attributes. The ones proposed as part of > this case all seem (more or less) reasonable. But the case also > outlines a scheme for extensibility. I would like the bounds for what > qualifies for inclusion to be as clear as possible. (And for extra > credit, I would like that hypothetical third party HSM vendor to be > able to deliver product without having to visit PSARC.) > > -- Glenn > In determining if an attribute should be considered a system attribute or should simply follow the current (opaque) extended attribute model, there will be black-and-white cases and there will be gray areas. For those gray areas, the project team's advice to the ARC is to challenge any proposal for new system attributes with the following questions: - Do operations on the file itself (e.g., open, read, write, close, unlink) cause the file system to modify the attribute? If so, then it's a system attribute. For example, writing to the file would cause the file system to set the AV_MODIFIED attribute. - Does the file system that implements the attribute make decisions based on the value of that attribute? If so, then it's a system attribute. For example, the file system will not allow a caller to write to anywhere but at the end of a file if the file has the APPENDONLY attribute set. - Does the kernel need to protect the format and/or value of the attribute for the value to be useful to consumers other than the one that set the value? If so, then it may be a system attribute. For example, CREATETIME must be in a time format (timestruc_t). - Is there a precedent in another operating system for the attribute being a system attribute? For example, on FreeBSD the NODUMP attribute is stored as a bit in the UFS inode and can be retrieved with stat(2) by ufsdump. - If all else fails, what justification does the project team have for proposing an attribute to be a system attribute as opposed to an opaque attribute? There may be legitimate reasons for proposing that an attribute be a system attribute. For example, an anti-virus facility integrated into Solaris might require a "scanstamp" to be stored as a system attribute for the following reasons: - If the virus-scanner needed to check the scanstamp on every open, that means each open must do an open and read on the extended attribute file containing the scanstamp which would be a severe performance penalty. - Storing the "scanstamp" as an extended attribute might be prohibitive since the file being scanned could itself be an extended attribute file. Recall that extended attributes on extended attributes may not be supported depending on the implementation. (See section 4.6 on the opinion for PSARC 1999/209). ... and we're not going to get that extra credit unless, of course, the hypothetical vendor agrees to using the existing (opaque) extended attribute facility. Changes to support new system attributes will touch enough to justify PSARC attention. Rich From Nicolas.Williams@sun.com Thu Jun 7 11:52:51 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 l57IqoPV019763 for ; Thu, 7 Jun 2007 11:52:51 -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 l57IpHwd027279; Thu, 7 Jun 2007 19:51:20 +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 <0JJA00I0P4DI0M00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 11:51:18 -0700 (PDT) Received: from localhost.Central.Sun.COM ([129.153.128.213]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJA000924DHLUA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 11:51:18 -0700 (PDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l57IoT20010204; Thu, 07 Jun 2007 13:50:29 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l57IoTqv010203; Thu, 07 Jun 2007 13:50:29 -0500 (CDT) Date: Thu, 07 Jun 2007 13:50:29 -0500 From: Nicolas Williams Subject: Re: 2007/315 [Extensible Attribute Interfaces] In-reply-to: <46685126.10907@Sun.COM> To: Rich Brown Cc: Glenn Skinner , PSARC-ext@sun.com, Tim.Haley@sun.com, Christopher.Kirby@sun.com, cifs-vfs-team@sun.com, Mark.Maybee@sun.com, Richard.Morris@sun.com Message-id: <20070607185029.GV9328@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: <200706061917.l56JHW5M002891@ivrel.sfbay.sun.com> <46685126.10907@Sun.COM> X-Authentication-warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 496 On Thu, Jun 07, 2007 at 01:40:38PM -0500, Rich Brown wrote: > For those gray areas, the project team's advice to the ARC is to > challenge any proposal for new system attributes with the following > questions: The first three can be collapsed into one: If the VFS or the FS itself implement semantics for the proposed system attribute that cannot be obtained from merely using extended attributes, then it's a system attribute (unless the feature is a bad idea anyways :) Nico -- From dwc@spartan.eng.sun.com Thu Jun 7 12:01:11 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 l57J1AhJ020251 for ; Thu, 7 Jun 2007 12:01:11 -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 l57IxJYk029876; Thu, 7 Jun 2007 19:59:40 +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 <0JJA00M1P4RFMY00@brm-avmta-1.central.sun.com>; Thu, 07 Jun 2007 12:59:39 -0600 (MDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJA00I944REV950@brm-avmta-1.central.sun.com>; Thu, 07 Jun 2007 12:59:38 -0600 (MDT) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l57IxbTv019478; Thu, 07 Jun 2007 11:59:37 -0700 (PDT) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l57IxbPQ019477; Thu, 07 Jun 2007 11:59:37 -0700 (PDT) Date: Thu, 07 Jun 2007 11:59:37 -0700 (PDT) From: Don Cragun Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] To: PSARC-ext@sun.com Cc: Garrett.Damore@sun.com, Rich.Brown@sun.com, cifs-vfs-team@sun.com, timh@spidey.central.sun.com Message-id: <200706071859.l57IxbPQ019477@spartan.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1098 The case materials say that this case will be allowing extensible attributes to be added presumably by any vendor/application writer that wants to add an attribute to a file. Discussion on this topic has implied that there will be no registration of extensible attributes because registration is complex, slow, etc. The case materials also state that utilities, including ls(1), will be modified to display all of the attributes associated with a file. Since there is no registration of attributes and none of the new interfaces being added here provide a textual description of the attributes, how is ls supposed to be able to display the attributes (at least those that are not included in this case) in any manner that will have any meaning to someone looking at the output from ls? Is it really going to help anyone if all ls can say is something like -rw-r--r-- (--SA--------) 1 dwc staff 5771 Jun 7 11:35 file Unknown Attributes: 0x00647763:00000002, 0x00647763:00000008, 0x00647763:00000040, 0x00647763:00000800 when it encounters unknown extensible attributes? - Don From dwc@spartan.eng.sun.com Thu Jun 7 12:09:16 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 l57J9Go4020424 for ; Thu, 7 Jun 2007 12:09:16 -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 l57J7QRl000253; Thu, 7 Jun 2007 13:07:27 -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 <0JJA00J0B551K000@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 12:07:49 -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 <0JJA00087550LSB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 12:07:48 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l57J7mdY019496; Thu, 07 Jun 2007 12:07:48 -0700 (PDT) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l57J7m0Y019495; Thu, 07 Jun 2007 12:07:48 -0700 (PDT) Date: Thu, 07 Jun 2007 12:07:48 -0700 (PDT) From: Don Cragun Subject: Re: 2007/315 [Extensible Attribute Interfaces] To: Rich.Brown@sun.com Cc: PSARC-ext@sun.com, Tim.Haley@sun.com, cifs-vfs-team@sun.com Message-id: <200706071907.l57J7m0Y019495@spartan.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 660 On Thu, 07 Jun 2007 13:40:38 -0500, Rich Brown wrote: >- Does the kernel need to protect the format and/or value of the > attribute for the value to be useful to consumers other than the one > that set the value? If so, then it may be a system attribute. > > For example, CREATETIME must be in a time format (timestruc_t). It would be nice if this were true, but timestruc_t uses signed values (giving a time range from well before the big bang to well after the projected end of the universe) while this project uses unsigned values (giving a time range from midnight Jan 1, 1970, UCT to much further after the projected end of the universe). - Don From Mark.Shellenbaum@Sun.COM Thu Jun 7 12:30:44 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 l57JUhJF020782 for ; Thu, 7 Jun 2007 12:30:44 -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 l57JSqxi009262; Fri, 8 Jun 2007 03:29:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJA00E0564PC000@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Jun 2007 12:29:13 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJA009YO64OEH60@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Jun 2007 12:29:12 -0700 (PDT) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l57JTCEo023148; Thu, 07 Jun 2007 19:29: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 <0JJA0000162W7000@mail-amer.sun.com> (original mail from Mark.Shellenbaum@Sun.COM); Thu, 07 Jun 2007 13:29:12 -0600 (MDT) Received: from [172.20.25.34] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJA0036D64NLDR2@mail-amer.sun.com>; Thu, 07 Jun 2007 13:29:11 -0600 (MDT) Date: Thu, 07 Jun 2007 13:29:11 -0600 From: Mark Shellenbaum Subject: Re: 2007/315 [Extensible Attribute Interfaces] In-reply-to: <200706070100.l5710Eec005092@marduk.eng.sun.com> Sender: Mark.Shellenbaum@Sun.COM To: Gary Winiger Cc: Rich.Brown@Sun.COM, glenn.skinner@Sun.COM, Christopher.Kirby@Sun.COM, Mark.Maybee@Sun.COM, PSARC-ext@Sun.COM, Richard.Morris@Sun.COM, cifs-vfs-team@Sun.COM, tim.haley@Sun.COM Message-id: <46685C87.3020805@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: <200706070100.l5710Eec005092@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 2491 Gary Winiger wrote: > I'm slowly getting caught up here. From my first reading, > I have two nits: The spec says micro binding. CIFS server I suspect > in minor. I don't believe there is any micro release planned. > I can see this project being useful before S11, perhaps a > patch binding is appropriate. > Oops... That's a typo. The team requests MINOR binding. > The man page says "Evolving" that should be "Committed". > This will be fixed > Now some real questions: Perhaps there's overlap with Glenn's line. > Perhaps this has been answered. As I asked in the meeting today, > a summary of the spec changes would. How is the Sun/Solaris distro > name space managed? I can see once zfs is bootable wanting to add > various "system" attributes. How will collisions be avoided with > other possible distros? > Rich sent a summary earlier today. New system attributes will be added in the xvattr_t/xoptattr_t data structures and stored in the file system as appropriate. These will be exposed as nvpairs in the SUNWattr_rw/SUNWattr_ro views as appropriate so there's no collision in the extended attribute namespace. As for the names of the attributes themselves (CREATETIME, READONLY, etc.) see section 4.4 Managing Change in the Attribute Space. > Can each attribute have a separate policy? For example, I may > wish to associate privileges with executables or file signatures > with each system data file. To view the privileges or signature > may not require any policy (beyond the default). However, to > modify should likely require some special policy. > A separate policy could be added for an individual attribute as needed but that isn't necessary for the proposed attributes. As discussed in a previous email, any work with signed files would be a future project. The current policies are defined in sections 3.1, 3.2 and 3.3. > Is there some thought that "system" attributes are ones that > require some policy either to view or modify? Putting that policy into place wouldn't be difficult to do but none of the proposed attributes have that requirement. > Perhaps defining what does NOT constitute a "system" attribute > would be helpful. One might say that other distros could use > the XXX_ro / XXX_rw name space. > Please see the previous response to Glenn's question about determining if an attribute is a system attribute. > I'm planning to go back over the materials and discussion again. > > Thankx, > Gary.. From Mark.Shellenbaum@sun.com Thu Jun 7 15:34:31 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 l57MYUDE027575 for ; Thu, 7 Jun 2007 15:34:31 -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 l57MWelU038269; Thu, 7 Jun 2007 16:32:41 -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 <0JJA00E03EN3IO00@brm-avmta-1.central.sun.com>; Thu, 07 Jun 2007 16:33:03 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJA005LQEN1OU50@brm-avmta-1.central.sun.com>; Thu, 07 Jun 2007 16:33:01 -0600 (MDT) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l57MX1Ma028759; Thu, 07 Jun 2007 22:33:01 +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 <0JJA00J01E7B0T00@mail-amer.sun.com> (original mail from Mark.Shellenbaum@Sun.COM); Thu, 07 Jun 2007 16:33:01 -0600 (MDT) Received: from [172.20.25.34] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJA00DWEEN1EJT4@mail-amer.sun.com>; Thu, 07 Jun 2007 16:33:01 -0600 (MDT) Date: Thu, 07 Jun 2007 16:33:00 -0600 From: Mark Shellenbaum Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200706071859.l57IxbPQ019477@spartan.SFBay.Sun.COM> Sender: Mark.Shellenbaum@sun.com To: Don Cragun Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com, Rich.Brown@sun.com, cifs-vfs-team@sun.com, timh@spidey.central.sun.com Message-id: <4668879C.4080104@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: <200706071859.l57IxbPQ019477@spartan.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 2244 Don Cragun wrote: > The case materials say that this case will be allowing extensible > attributes to be added presumably by any vendor/application writer that > wants to add an attribute to a file. Discussion on this topic has > implied that there will be no registration of extensible attributes > because registration is complex, slow, etc. The case materials also > state that utilities, including ls(1), will be modified to display all > of the attributes associated with a file. > > Since there is no registration of attributes and none of the new > interfaces being added here provide a textual description of the > attributes, how is ls supposed to be able to display the attributes (at > least those that are not included in this case) in any manner that will > have any meaning to someone looking at the output from ls? > > Is it really going to help anyone if all ls can say is something like > > -rw-r--r-- (--SA--------) 1 dwc staff 5771 Jun 7 11:35 file > Unknown Attributes: 0x00647763:00000002, 0x00647763:00000008, 0x00647763:00000040, 0x00647763:00000800 > > when it encounters unknown extensible attributes? > > - Don > Although this case allows for system attributes to be added, it does not presume that anyone can add any system attribute without ARC approval. As stated in an earlier e-mail to Glenn: Changes to support new system attributes will touch enough to justify PSARC attention. Also, please see section 4.4 Managing Change in the Attribute Space. As for displaying the attributes via 'ls', there is a separate effort by the Utilities Group to tackle this problem. There are two things that this project team can suggest: - Project teams that propose new system attributes are responsible for all aspects of those attributes. Including the decisions on whether or not they are set by a user-level API and whether or not they are displayed by ls(1) or any other utility. This project team cannot predict what future attributes will be proposed. - The Utilities Team may choose to take advantage of the nvpair format returned by fgetattr(). This will allow them to format and display (name and value) all available system attributes. -Mark From lists@mcintyreweb.com Thu Jun 7 21:24:59 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 l584OxvW005869 for ; Thu, 7 Jun 2007 21:24:59 -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 l584NQpq013576; Fri, 8 Jun 2007 05:23:28 +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 <0JJA00605UV2XW00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 21:23:26 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJA004DZUV1FU10@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Jun 2007 21:23:26 -0700 (PDT) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l584NPQE012994; Fri, 08 Jun 2007 04:23:25 +0000 (GMT) Received: from mms22es.sun.com ([150.143.232.34] [150.143.232.34]) by relay22.sun.com with ESMTP id BT-MMP-1134039; Fri, 08 Jun 2007 04:23:25 +0000 (Z) Received: from mms25bas.mms.us.syntegra.com (ip192-12-251-90.block6.us.syntegra.com [192.12.251.90]) by mms22es.sun.com with ESMTP id BT-MMP-12466; Fri, 08 Jun 2007 04:23:25 +0000 (Z) Received: from partslist.i.mcintyreweb.com ([64.166.3.74] [64.166.3.74]) by relay21.sun.com with ESMTP id BT-MMP-9367178; Fri, 08 Jun 2007 04:23:24 +0000 (Z) Received: from [127.0.0.1] (localhost [127.0.0.1]) by partslist.i.mcintyreweb.com (8.13.8+Sun/8.13.8) with ESMTP id l584NIJE015074; Thu, 07 Jun 2007 21:23:19 -0700 (PDT) Date: Thu, 07 Jun 2007 21:23:18 -0700 From: Hugh McIntyre Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <4668879C.4080104@Sun.COM> To: Mark Shellenbaum Cc: Don Cragun , PSARC-ext@sun.com, cifs-vfs-team@sun.com, timh@spidey.central.sun.com.mcintyreweb.com, Garrett.Damore@sun.com, Rich.Brown@sun.com Message-id: <4668D9B6.9010407@mcintyreweb.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706071859.l57IxbPQ019477@spartan.SFBay.Sun.COM> <4668879C.4080104@Sun.COM> User-Agent: Thunderbird 1.5.0.10 (X11/20070303) Status: RO Content-Length: 928 Mark Shellenbaum wrote: > As for displaying the attributes via 'ls', there is a separate > effort by the Utilities Group to tackle this problem. There are > two things that this project team can suggest: As one datapoint, MacOS doesn't display anything for extended attributes unless you use "ls -lo". And then if you do, sample output is: % touch foo % chflags uchg,opaque,nodump,uappend foo % ls -lo foo -rw-r--r-- 1 hugh wheel uappnd,uchg,nodump,opaque 0 Jun 7 21:08 foo (there are many other flags) Note that "-o" is already used for something else on Solaris, however. > - The Utilities Team may choose to take advantage of the nvpair > format returned by fgetattr(). This will allow them to format > and display (name and value) all available system attributes. Maybe a good idea, but also maybe incompatible with the "ls" format above. Not that this should necessarily stop this choice. Hugh. From don.cragun@sun.com Fri Jun 8 09:08:57 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 l58G8uKO017902 for ; Fri, 8 Jun 2007 09:08:57 -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 l58G7NUd003712; Fri, 8 Jun 2007 17:07:25 +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 <0JJB00J0NRGB7O00@brm-avmta-1.central.sun.com>; Fri, 08 Jun 2007 10:07:23 -0600 (MDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJB00AQJRGBZTB0@brm-avmta-1.central.sun.com>; Fri, 08 Jun 2007 10:07:23 -0600 (MDT) 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 l58G7M5W020948; Fri, 08 Jun 2007 09:07:22 -0700 (PDT) Date: Fri, 08 Jun 2007 09:07:22 -0700 (PDT) From: Don Cragun Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] To: Mark.Shellenbaum@sun.com Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com, Rich.Brown@sun.com, cifs-vfs-team@sun.com, timh@spidey.central.sun.com Reply-to: Don Cragun Message-id: <200706081607.l58G7M5W020948@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: zos0NekWx6cMhHV6XDOCVg== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 3084 On Thu, 07 Jun 2007 16:33:00 -0600, Mark Shellenbaum wrote: >Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] > >Don Cragun wrote: >> The case materials say that this case will be allowing extensible >> attributes to be added presumably by any vendor/application writer that >> wants to add an attribute to a file. Discussion on this topic has >> implied that there will be no registration of extensible attributes >> because registration is complex, slow, etc. The case materials also >> state that utilities, including ls(1), will be modified to display all >> of the attributes associated with a file. >> >> Since there is no registration of attributes and none of the new >> interfaces being added here provide a textual description of the >> attributes, how is ls supposed to be able to display the attributes (at >> least those that are not included in this case) in any manner that will >> have any meaning to someone looking at the output from ls? >> >> Is it really going to help anyone if all ls can say is something like >> >> -rw-r--r-- (--SA--------) 1 dwc staff 5771 Jun 7 11:35 file >> Unknown Attributes: 0x00647763:00000002, 0x00647763:00000008, 0x00647763:00000040, 0x00647763:00000800 >> >> when it encounters unknown extensible attributes? >> >> - Don >> > > >Although this case allows for system attributes to be added, it >does not presume that anyone can add any system attribute without >ARC approval. As stated in an earlier e-mail to Glenn: > > Changes to support new system attributes will touch > enough to justify PSARC attention. This sort of works for "system" attributes. PSARC becomes the registration authority for "system" extensible attributes, and any case coming to PSARC for a new system attribute will have to include an update to [at least] ls(1). It doesn't work for non-"system" attributes. > >Also, please see section 4.4 Managing Change in the Attribute Space. > >As for displaying the attributes via 'ls', there is a separate >effort by the Utilities Group to tackle this problem. There are >two things that this project team can suggest: > >- Project teams that propose new system attributes are responsible > for all aspects of those attributes. Including the decisions on > whether or not they are set by a user-level API and whether or not > they are displayed by ls(1) or any other utility. > > This project team cannot predict what future attributes will be > proposed. > >- The Utilities Team may choose to take advantage of the nvpair > format returned by fgetattr(). This will allow them to format > and display (name and value) all available system attributes. This case should be providing the basic infrastructure to enable extensible attributes to be used correctly. It seems to me that this project is incomplete for two reasons: 1. it doesn't provide a mechanism for extensible attributes to identify themselves, and 2. it doesn't provide a registration mechanism for non-"system" extensible attributes. - Don From Mark.Shellenbaum@sun.com Fri Jun 8 10:40:12 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 l58HeBMY022499 for ; Fri, 8 Jun 2007 10:40:11 -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 l58HcSIh013312; Sat, 9 Jun 2007 01:38:40 +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 <0JJB00G03VOCB600@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Jun 2007 10:38:36 -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 <0JJB007V6VOCWK60@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Jun 2007 10:38:36 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l58HcaCR003874; Fri, 08 Jun 2007 17:38: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 <0JJB00901VH8VN00@mail-amer.sun.com> (original mail from Mark.Shellenbaum@Sun.COM); Fri, 08 Jun 2007 11:38:36 -0600 (MDT) Received: from [172.20.25.34] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJB003D4VOBNCO7@mail-amer.sun.com>; Fri, 08 Jun 2007 11:38:36 -0600 (MDT) Date: Fri, 08 Jun 2007 11:38:35 -0600 From: Mark Shellenbaum Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200706081607.l58G7M5W020948@spartan.SFBay.Sun.COM> Sender: Mark.Shellenbaum@sun.com To: Don Cragun Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com, Rich.Brown@sun.com, cifs-vfs-team@sun.com, timh@spidey.central.sun.com Message-id: <4669941B.6090903@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: <200706081607.l58G7M5W020948@spartan.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 4046 Don Cragun wrote: > On Thu, 07 Jun 2007 16:33:00 -0600, Mark Shellenbaum wrote: >> Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout > 06/06/2007] >> Don Cragun wrote: >>> The case materials say that this case will be allowing extensible >>> attributes to be added presumably by any vendor/application writer that >>> wants to add an attribute to a file. Discussion on this topic has >>> implied that there will be no registration of extensible attributes >>> because registration is complex, slow, etc. The case materials also >>> state that utilities, including ls(1), will be modified to display all >>> of the attributes associated with a file. >>> >>> Since there is no registration of attributes and none of the new >>> interfaces being added here provide a textual description of the >>> attributes, how is ls supposed to be able to display the attributes (at >>> least those that are not included in this case) in any manner that will >>> have any meaning to someone looking at the output from ls? >>> >>> Is it really going to help anyone if all ls can say is something like >>> >>> -rw-r--r-- (--SA--------) 1 dwc staff 5771 Jun 7 11:35 file >>> Unknown Attributes: 0x00647763:00000002, 0x00647763:00000008, > 0x00647763:00000040, 0x00647763:00000800 >>> when it encounters unknown extensible attributes? >>> >>> - Don >>> >> >> Although this case allows for system attributes to be added, it >> does not presume that anyone can add any system attribute without >> ARC approval. As stated in an earlier e-mail to Glenn: >> >> Changes to support new system attributes will touch >> enough to justify PSARC attention. > > This sort of works for "system" attributes. PSARC becomes the > registration authority for "system" extensible attributes, and any case > coming to PSARC for a new system attribute will have to include an > update to [at least] ls(1). It doesn't work for non-"system" > attributes. > This case is specific to system attributes. Except for exposing the two extended attribute files (SUNWattr_rw and SUNWattr_ro) which are really views into the optional system attributes, the project team does not desire to change any of the policy from PSARC 1999/209 (Extended File Attributes). >> Also, please see section 4.4 Managing Change in the Attribute Space. >> >> As for displaying the attributes via 'ls', there is a separate >> effort by the Utilities Group to tackle this problem. There are >> two things that this project team can suggest: >> >> - Project teams that propose new system attributes are responsible >> for all aspects of those attributes. Including the decisions on >> whether or not they are set by a user-level API and whether or not >> they are displayed by ls(1) or any other utility. >> >> This project team cannot predict what future attributes will be >> proposed. >> >> - The Utilities Team may choose to take advantage of the nvpair >> format returned by fgetattr(). This will allow them to format >> and display (name and value) all available system attributes. > > This case should be providing the basic infrastructure to enable > extensible attributes to be used correctly. It seems to me that this > project is incomplete for two reasons: > 1. it doesn't provide a mechanism for extensible attributes to > identify themselves, and See the fgetattr.3c man page in the materials directory. Specifically "Example 1". fgetattr() returns an nvlist_t which is composed of nvpair_t's of all the system attributes supported by this file system. The application can then iterate through each nvpair in the nvlist and use the interfaces in the nvpair library to determine the name, type, and value of the attribute(s). > 2. it doesn't provide a registration mechanism for non-"system" > extensible attributes. > As mentioned above, this case is about extensible system attributes. The project team is not asking for any policy change for extended attributes described in PSARC 1999/209. -Mark From don.cragun@sun.com Fri Jun 8 19:16:07 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 l592G6w5006476 for ; Fri, 8 Jun 2007 19:16:06 -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 l592EU91011887; Sat, 9 Jun 2007 10:14: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 <0JJC00I01JK7A500@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Jun 2007 19:14:31 -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 <0JJC0065TJK7F430@nwk-avmta-1.sfbay.Sun.COM>; Fri, 08 Jun 2007 19:14:31 -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 l592ENmR021855; Fri, 08 Jun 2007 19:14:23 -0700 (PDT) Date: Fri, 08 Jun 2007 19:14:23 -0700 (PDT) From: Don Cragun Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] To: Mark.Shellenbaum@sun.com Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com, Rich.Brown@sun.com, cifs-vfs-team@sun.com, timh@spidey.central.sun.com Reply-to: Don Cragun Message-id: <200706090214.l592ENmR021855@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: V+1DIiAfMlFvXqKOFe3H+g== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5224 Mark, Parts of the following comments were answered during our discussion this afternoon. Others came up when I went back and looked at the proposal again after our discussion. I think it may help to have responses on file in the case directory... >On Fri, 08 Jun 2007 11:38:35 -0600, Mark Shellenbaum wrote: >> Don Cragun wrote: ... ... ... >This case is specific to system attributes. I'm confused. If this case is specific to system attributes, why does it start by saying ``The Solaris CIFS project requires file system support for a number of "system" and opaque file attributes.'' Aren't the opaque file attributes in this case CIFS project-related non-"system" attributes? The way I read the case, opaque attributes are not necessarily "system" attributes. Furthermore, the commentary on this case has stated that "the system attributes will be present on all file system objects" on a ZFS file system, but strongly implies that opaque attributes will not be present on every file system object. >Except for exposing the two extended attribute files (SUNWattr_rw and >SUNWattr_ro) which are really views into the optional system attributes, >the project team does not desire to change any of the policy from PSARC >1999/209 (Extended File Attributes). > >>> Also, please see section 4.4 Managing Change in the Attribute Space. >>> >>> As for displaying the attributes via 'ls', there is a separate >>> effort by the Utilities Group to tackle this problem. There are >>> two things that this project team can suggest: I know. I'm working with that team and I'm not sure they have enough information to successfully complete the changes needed to support the "extensible" part of this project. >>> >>> - Project teams that propose new system attributes are responsible >>> for all aspects of those attributes. Including the decisions on >>> whether or not they are set by a user-level API and whether or not >>> they are displayed by ls(1) or any other utility. >>> >>> This project team cannot predict what future attributes will be >>> proposed. >>> >>> - The Utilities Team may choose to take advantage of the nvpair >>> format returned by fgetattr(). This will allow them to format >>> and display (name and value) all available system attributes. Not unless this case is setting a precedent requiring that all future "system" attributes be implemented using nvpairs and that the headers describing all new system attributes must be available to utilities built in the ON consolidation. It also requires that updated versions of these utilities be available everywhere on a network when new system attributes are added to any filesystem on the network... ;-{ >> >> This case should be providing the basic infrastructure to enable >> extensible attributes to be used correctly. It seems to me that this >> project is incomplete for two reasons: >> 1. it doesn't provide a mechanism for extensible attributes to >> identify themselves, and > >See the fgetattr.3c man page in the materials directory. Specifically >"Example 1". > >fgetattr() returns an nvlist_t which is composed of nvpair_t's of all >the system attributes supported by this file system. The application >can then iterate through each nvpair in the nvlist and use the >interfaces in the nvpair library to determine the name, type, and value >of the attribute(s). Maybe. It does for now, but I see nothing in this case that requires that future system attributes be stored as nvpairs, reside in one of the two new attribute files created by this project, nor that they be retrievable and settable by f[gs]etattr() and [gs]etattrat(). 1999/209 created extended attributes; this case creates more extended attributes. I don't see any guarantees that the next set of extended attributes is required to, nor will be able to, use the same mechanism presented here. ... ... ... You also seem to have tripped over one of my pet peeves from 1999/209 again. This case adds system attributes that clearly are intended to modify the behavior of operations on directories, but you repeatedly state that these extensible system attributes are only associated with "regular file"s. Since a directory is a file of type directory, it is not a regular file. (Symlinks, sockets, doors, block-special, and character-special files aren't regular files either.) The new SUNWattr_ro and SUNWattr_rw attribute files are regular files. You explicitly state that "recursive system attributes (sysattrs on sysattrs) are not allowed", but there is no way for the utilities to know which attribute files found in the alternate address space are describe sysattrs and which describe other extended attributes other than by being patched every time a new system attribute is created. I would have thought that an "extensible" set of new attributes would include a way for applications to determine at run time (without being rebuilt) which attribute files describe sysattrs, what the names of the attributes are (without reading a header), and how to process sysattrs so that archive creators and restorers could work without modification when new attrs are added later. Clearly, I was hoping for too much. 8-{ > > -Mark From schilling@fokus.fraunhofer.de Sat Jun 9 06:57:21 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 l59DvKQM021170 for ; Sat, 9 Jun 2007 06:57:21 -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 l59DtmAc002801; Sat, 9 Jun 2007 21:55:48 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JJD00N01G0Z1H00@brm-avmta-1.central.sun.com>; Sat, 09 Jun 2007 07:55:47 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJD00LPSG0YMY80@brm-avmta-1.central.sun.com>; Sat, 09 Jun 2007 07:55:46 -0600 (MDT) Received: from relay2.sun.com (relay2.sun.com [150.143.103.24] (may be forged)) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l59DWqPV022055; Sat, 09 Jun 2007 13:55:46 +0000 (GMT) Received: from mms02es.sun.com ([150.143.104.34] [150.143.104.34]) by relay2.sun.com with ESMTP id BT-MMP-1380738; Sat, 09 Jun 2007 13:55:46 +0000 (Z) Received: from relay4.sun.com (relay4.sun.com [150.143.103.74]) by mms02es.sun.com with ESMTP id BT-MMP-83642; Sat, 09 Jun 2007 13:55:46 +0000 (Z) Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72]) by relay4.sun.com with ESMTP id BT-MMP-7451468; Sat, 09 Jun 2007 13:55:45 +0000 (Z) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14] [193.174.154.14]) by relay4i.sun.com with ESMTP id BT-MMP-1693249; Sat, 09 Jun 2007 13:55:45 +0000 (Z) Received: from burner.fokus.fraunhofer.de (burner [10.147.65.166]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id l59DteF11958; Sat, 09 Jun 2007 15:55:40 +0200 (MEST) Received: (from jes@localhost) by burner.fokus.fraunhofer.de (8.12.9+Sun/8.12.9/Submit) id l59DsBp9021006; Sat, 09 Jun 2007 15:54:11 +0200 (CEST) Date: Sat, 09 Jun 2007 15:54:11 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <4668D9B6.9010407@mcintyreweb.com> Sender: schilling@fokus.fraunhofer.de To: Mark.Shellenbaum@sun.com, lists@mcintyreweb.com Cc: timh@spidey.central.sun.com.mcintyreweb.com, Rich.Brown@sun.com, PSARC-ext@sun.com, Garrett.Damore@sun.com, don.cragun@sun.com, cifs-vfs-team@sun.com Message-id: <466ab103.Hqm+ED4QQPEiOv8Y%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.2.0.264296 References: <200706071859.l57IxbPQ019477@spartan.SFBay.Sun.COM> <4668879C.4080104@Sun.COM> <4668D9B6.9010407@mcintyreweb.com> User-Agent: nail 11.22 3/20/05 Status: RO Content-Length: 1179 Hugh McIntyre wrote: > Mark Shellenbaum wrote: > > As for displaying the attributes via 'ls', there is a separate > > effort by the Utilities Group to tackle this problem. There are > > two things that this project team can suggest: > > As one datapoint, MacOS doesn't display anything for extended attributes > unless you use "ls -lo". And then if you do, sample output is: > > % touch foo > % chflags uchg,opaque,nodump,uappend foo > % ls -lo foo > -rw-r--r-- 1 hugh wheel uappnd,uchg,nodump,opaque 0 Jun 7 21:08 foo > > (there are many other flags) > > Note that "-o" is already used for something else on Solaris, however. This has been taken from FreeBSD. The -o flag is a SysV option that has been around for more than 20 years. This option is part of the POSIX standard. Unfortunately FreeBSD did choose -o for printing file flags. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily From Mark.Shellenbaum@sun.com Mon Jun 11 13:12:19 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 l5BKCItl007852 for ; Mon, 11 Jun 2007 13:12:19 -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 l5BKAhpp009634; Mon, 11 Jun 2007 21:10: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 <0JJH0070PMPW7C00@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 14:10:44 -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 <0JJH00KOZMPV15A0@brm-avmta-1.central.sun.com>; Mon, 11 Jun 2007 14:10:43 -0600 (MDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5BKAhPJ027767; Mon, 11 Jun 2007 20:10: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 <0JJH00701MOJU200@mail-amer.sun.com> (original mail from Mark.Shellenbaum@Sun.COM); Mon, 11 Jun 2007 14:10:43 -0600 (MDT) Received: from [172.20.25.34] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJH008HMMPT3Z71@mail-amer.sun.com>; Mon, 11 Jun 2007 14:10:41 -0600 (MDT) Date: Mon, 11 Jun 2007 14:10:40 -0600 From: Mark Shellenbaum Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200706090214.l592ENmR021855@spartan.SFBay.Sun.COM> Sender: Mark.Shellenbaum@sun.com To: Don Cragun Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com, Rich.Brown@sun.com, cifs-vfs-team@sun.com, timh@spidey.central.sun.com Message-id: <466DAC40.8050203@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: <200706090214.l592ENmR021855@spartan.SFBay.Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 10615 Based on some of the questions we've gotten and the discussions we've had, the project team has realized that there is some confusion that we need to clear up. Our apologies for not realizing this sooner and for not explaining this well enough in the original spec. There are three distinct types of file attributes: - Standard file attributes are the file attributes that are returned with the stat(2) system call. - Extended attributes as described by PSARC 1999/209 Extended File Attributes - Extensible system attributes as described by this case. There are two specific, intentional areas where the interfaces that deal with extensible system attributes overlap with the other two types: * Standard file attributes and the extensible system attributes are retrieved and set using VOP_GETATTR() and VOP_SETATTR() respectively. It's the xvattr_t which allows extensible system attributes to be retrieved and set through the VOP_GETATTR() and VOP_SETATTR() interfaces. Section 4.3 of the spec describes these interfaces. * Extensible system attributes can be viewed through two special extended attribute files: SUNWattr_ro and SUNWattr_rw. Section 4.1.1 of the spec has a list of which attributes are viewable via SUNWattr_rw vs. SUNWattr_ro. Any additions to the extensible system attributes (whether from Sun project teams or Opensolaris project teams) will be retrieved and manipulated by the same interfaces being proposed here. Specifically: - Extensible system attributes can be retrieved via fgetattr() and getattrat(). - Extensible system attributes can be modified via fsetattr() and setattrat(). - Extensible system attributes are retrieved and set using VOP_GETATTR() and VOP_SETATTR() respectively. - Extensible system attributes can be viewed through two special extended attribute files: SUNWattr_ro and SUNWattr_rw. The project team that proposes any new extensible system attributes must take full responsibility for the following: - Updates to fgetattr()/getattrat()/fsetattr()/setattrat() library functions and the appropriate header files. - Updates to the xvattr_t/xoptattr_t structures and the appropriate header files - Updates to the xattr facility to support these new attributes in SUNWattr_rw and SUNWattr_ro. - Working with the utilities team to decide which (if any) commands need to change and what those changes are. Since the extensible system attributes are available through the SUNWattr_rw/SUNWattr_ro views, then the changes to archiver tools should be minimal (depending on the semantics of the new attributes). One note on potential future work: It's possible that future projects might propose other views as different needs arise. This project team sees the SUNWattr_rw and SUNWattr_ro extended attribute files to be sufficient for the current needs. Reponses to Don's questions are inline below... Don Cragun wrote: > Mark, > Parts of the following comments were answered during our discussion > this afternoon. Others came up when I went back and looked at the > proposal again after our discussion. I think it may help to have > responses on file in the case directory... > >> On Fri, 08 Jun 2007 11:38:35 -0600, Mark Shellenbaum wrote: >>> Don Cragun wrote: > ... ... ... >> This case is specific to system attributes. > > I'm confused. > > If this case is specific to system attributes, why does it start by > saying ``The Solaris CIFS project requires file system support for a > number of "system" and opaque file attributes.'' Aren't the opaque > file attributes in this case CIFS project-related non-"system" > attributes? > Unfortunately, the comment about opaque file attributes was left over from a previous document which likely led to unnecessary confusion. The CIFS server will use the extended attribute facility or "opaque" attributes for named streams. Two special extended attribute files can be used as a view into the extensible system attributes: SUNWattr_rw and SUNWattr_ro. Aside from that specific overlap, extended attribute and extensible system attributes are two different types of attributes. > The way I read the case, opaque attributes are not necessarily "system" > attributes. Furthermore, the commentary on this case has stated that > "the system attributes will be present on all file system objects" on a > ZFS file system, but strongly implies that opaque attributes will not > be present on every file system object. > Yes, except that if a file has extensible system attributes then the SUNWattr_rw and SUNWattr_ro extended attribute files will be available since they will be the views into the extensible system attributes. >> Except for exposing the two extended attribute files (SUNWattr_rw and >> SUNWattr_ro) which are really views into the optional system attributes, >> the project team does not desire to change any of the policy from PSARC >> 1999/209 (Extended File Attributes). >> >>>> Also, please see section 4.4 Managing Change in the Attribute Space. >>>> >>>> As for displaying the attributes via 'ls', there is a separate >>>> effort by the Utilities Group to tackle this problem. There are >>>> two things that this project team can suggest: > > I know. I'm working with that team and I'm not sure they have enough > information to successfully complete the changes needed to support the > "extensible" part of this project. > Good. For the record, the members of this team have also been working closely with the utilities team. >>>> - Project teams that propose new system attributes are responsible >>>> for all aspects of those attributes. Including the decisions on >>>> whether or not they are set by a user-level API and whether or not >>>> they are displayed by ls(1) or any other utility. >>>> >>>> This project team cannot predict what future attributes will be >>>> proposed. >>>> >>>> - The Utilities Team may choose to take advantage of the nvpair >>>> format returned by fgetattr(). This will allow them to format >>>> and display (name and value) all available system attributes. > > Not unless this case is setting a precedent requiring that all future > "system" attributes be implemented using nvpairs and that the headers > describing all new system attributes must be available to utilities > built in the ON consolidation. It also requires that updated versions > of these utilities be available everywhere on a network when new > system attributes are added to any filesystem on the network... ;-{ > All future system attributes will be available as nvlists of nvpairs through the views provided by the SUNWattr_rw or SUNWattr_ro view extended attribute files, as appropriate. Should the utilities team choose to take this direction (separate, but related case) then clearly the utilities would be able to read and display all of the extensible system attributes on a file. They would not necessarily be able to SET those attributes since there may be semantics associated with the new attributes for which the utilities may need to be aware of. The team feels this is the best that can be expected of the project. >>> This case should be providing the basic infrastructure to enable >>> extensible attributes to be used correctly. It seems to me that this >>> project is incomplete for two reasons: >>> 1. it doesn't provide a mechanism for extensible attributes to >>> identify themselves, and >> See the fgetattr.3c man page in the materials directory. Specifically >> "Example 1". >> >> fgetattr() returns an nvlist_t which is composed of nvpair_t's of all >> the system attributes supported by this file system. The application >> can then iterate through each nvpair in the nvlist and use the >> interfaces in the nvpair library to determine the name, type, and value >> of the attribute(s). > > Maybe. It does for now, but I see nothing in this case that requires > that future system attributes be stored as nvpairs, reside in one of > the two new attribute files created by this project, nor that they be > retrievable and settable by f[gs]etattr() and [gs]etattrat(). 1999/209 > created extended attributes; this case creates more extended > attributes. I don't see any guarantees that the next set of extended > attributes is required to, nor will be able to, use the same mechanism > presented here. > The clarifications in the first part of this response should clear this confusion up. One other point to make clear: The extensible system attributes are not stored in an extended attribute. They are stored in the file system and can be *viewed* as an nvlist of nvpairs through SUNWattr_rw/SUNWattr_ro. > ... ... ... > > You also seem to have tripped over one of my pet peeves from 1999/209 > again. This case adds system attributes that clearly are intended to > modify the behavior of operations on directories, but you repeatedly > state that these extensible system attributes are only associated with > "regular file"s. Since a directory is a file of type directory, it is > not a regular file. (Symlinks, sockets, doors, block-special, and > character-special files aren't regular files either.) > Point taken. We'll update the spec to be more precise. To be clear, there are two file types to which the extensible system attributes apply: regular and directory files. > The new SUNWattr_ro and SUNWattr_rw attribute files are regular files. > You explicitly state that "recursive system attributes (sysattrs on > sysattrs) are not allowed", but there is no way for the utilities to > know which attribute files found in the alternate address space are > describe sysattrs and which describe other extended attributes other > than by being patched every time a new system attribute is created. I > would have thought that an "extensible" set of new attributes would > include a way for applications to determine at run time (without being > rebuilt) which attribute files describe sysattrs, what the names of the > attributes are (without reading a header), and how to process sysattrs > so that archive creators and restorers could work without modification > when new attrs are added later. Clearly, I was hoping for too much. 8-{ > > Regardless of how many new system attributes are added, the only two extended attribute files needed to view them are SUNWattr_rw and SUNWattr_ro. As mentioned previously other projects may propose alternate views in the future, but this project team sees the SUNWattr_rw and SUNWattr_ro extended attribute files to be sufficient for the current needs. -Mark From gww@eng.sun.com Tue Jun 12 18:31:44 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 l5D1VixL023738 for ; Tue, 12 Jun 2007 18:31:44 -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 l5D1UChN006268; Tue, 12 Jun 2007 18:30:13 -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 <0JJJ00I03W6CAH00@brm-avmta-1.central.sun.com>; Tue, 12 Jun 2007 19:30:12 -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 <0JJJ00N5TW6B35B0@brm-avmta-1.central.sun.com>; Tue, 12 Jun 2007 19:30:11 -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 l5D1U9iU015911; Tue, 12 Jun 2007 18:30:09 -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 l5D1WhjM011299; Tue, 12 Jun 2007 18:32:43 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5D1WhGY011298; Tue, 12 Jun 2007 18:32:43 -0700 (PDT) Date: Tue, 12 Jun 2007 18:32:43 -0700 (PDT) From: Gary Winiger Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] To: Mark.Shellenbaum@sun.com, don.cragun@sun.com Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com, Rich.Brown@sun.com, cifs-vfs-team@sun.com, timh@spidey.central.sun.com Message-id: <200706130132.l5D1WhGY011298@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 465 > Based on some of the questions we've gotten and the discussions we've > had, the project team has realized that there is some confusion that we > need to clear up. Our apologies for not realizing this sooner and for > not explaining this well enough in the original spec. Thanks. I believe this converges things for me. > Point taken. We'll update the spec to be more precise. At least for me, I'd like to see the update before final approval. Gary.. From Rich.Brown@sun.com Tue Jun 12 19:26:16 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 l5D2QGxk024847 for ; Tue, 12 Jun 2007 19:26:16 -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 l5D2OiOM013604; Tue, 12 Jun 2007 19:24:45 -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 <0JJJ00M05YP8JI00@brm-avmta-1.central.sun.com>; Tue, 12 Jun 2007 20:24:44 -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 <0JJJ00NADYP73AE0@brm-avmta-1.central.sun.com>; Tue, 12 Jun 2007 20:24:43 -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 l5D2OhXs002662; Wed, 13 Jun 2007 02:24: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 <0JJJ00I01YBTL500@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Tue, 12 Jun 2007 20:24:43 -0600 (MDT) Received: from [129.147.9.135] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJJ0080BYP63V23@mail-amer.sun.com>; Tue, 12 Jun 2007 20:24:43 -0600 (MDT) Date: Tue, 12 Jun 2007 21:24:42 -0500 From: Rich Brown Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200706130132.l5D1WhGY011298@marduk.eng.sun.com> Sender: Rich.Brown@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, cifs-vfs-team@sun.com, timh@spidey.central.sun.com Message-id: <466F556A.3070003@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: <200706130132.l5D1WhGY011298@marduk.eng.sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 682 Gary Winiger wrote: >> Based on some of the questions we've gotten and the discussions we've >> had, the project team has realized that there is some confusion that we >> need to clear up. Our apologies for not realizing this sooner and for >> not explaining this well enough in the original spec. > > Thanks. I believe this converges things for me. > >> Point taken. We'll update the spec to be more precise. > > At least for me, I'd like to see the update before final > approval. > > Gary.. Hi Gary, I expect that the updated spec will be available between 8AM and 9AM Pacific. We'll include the diffs from the original spec to expedite matters. Thanks, Rich From Rich.Brown@sun.com Wed Jun 13 08:17:04 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 l5DFH4gu008364 for ; Wed, 13 Jun 2007 08:17:04 -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 l5DFF41F012976; Wed, 13 Jun 2007 09:15:06 -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 <0JJK0064NYDUVX00@brm-avmta-1.central.sun.com>; Wed, 13 Jun 2007 09:15:30 -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 <0JJK004IOYDSSQ20@brm-avmta-1.central.sun.com>; Wed, 13 Jun 2007 09:15:28 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5DFFSJM027003; Wed, 13 Jun 2007 15:15: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 <0JJK00401W3KI900@mail-amer.sun.com> (original mail from Rich.Brown@Sun.COM); Wed, 13 Jun 2007 09:15:28 -0600 (MDT) Received: from [129.147.9.135] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJK00MV1YDD2G9J@mail-amer.sun.com>; Wed, 13 Jun 2007 09:15:15 -0600 (MDT) Date: Wed, 13 Jun 2007 10:15:13 -0500 From: Rich Brown Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200706130132.l5D1WhGY011298@marduk.eng.sun.com> Sender: Rich.Brown@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, cifs-vfs-team@sun.com, Tim Haley Message-id: <46700A01.6000209@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_SQ3sL0mXWKpDMaZs2ikZdA)" X-PMX-Version: 5.2.0.264296 References: <200706130132.l5D1WhGY011298@marduk.eng.sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 43472 This is a multi-part message in MIME format. --Boundary_(ID_SQ3sL0mXWKpDMaZs2ikZdA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Gary Winiger wrote: >> Based on some of the questions we've gotten and the discussions we've >> had, the project team has realized that there is some confusion that we >> need to clear up. Our apologies for not realizing this sooner and for >> not explaining this well enough in the original spec. > > Thanks. I believe this converges things for me. > >> Point taken. We'll update the spec to be more precise. > > At least for me, I'd like to see the update before final > approval. > > Gary.. Gary, See the attached files: spec_diffs.txt - diff output against the original spec sysattrs-spec-3.txt - updated spec The team will be attending the PSARC meeting today. Rich --Boundary_(ID_SQ3sL0mXWKpDMaZs2ikZdA) Content-type: text/plain; name=spec_diffs.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=spec_diffs.txt 1.0 CONTEXT 27a28 > The project team requests MINOR binding. 32,34c33,35 2.0 OVERVIEW < "system" and opaque file attributes. For file systems that fully < support CIFS, the system attributes will be present on all file < system objects and the file system will need to update the --- > new "system" attributes. For file systems that fully support CIFS, the > system attributes will be present on all regular files, directories, and > opaque extended attribute files. The file system will need to update the 43,44c44,45 < In order to accommodate the existing extended attribute aware < utilities in Solaris, the new attributes will be exposed via the --- > In order to accommodate the existing extended attribute aware utilities > in Solaris, the new attributes will be exposed as "views" via the 47,49c48 < attributes in a single file composed as a packed nvlist. Since all < files will have these new attributes, they need to be stored and < accessed as efficiently as possible. --- > attributes in a single file composed as an XDR packed nvlist. 54a54,81 > It's important to note that there are three distinct types of file > attributes being discussed: > > - Standard file attributes are the file attributes that are returned > with the stat(2) system call. > > - Extended attributes as described by PSARC 1999/209 Extended File > Attributes. > > - Extensible system attributes as described by this case. > > There are two specific, intentional areas where the interfaces that > deal with extensible system attributes overlap with the other two > types: > > * Standard file attributes and the extensible system attributes are > retrieved and set using VOP_GETATTR() and VOP_SETATTR() > respectively. > > Section 4.3 of the spec describes these interfaces and their > extensions. > > * Extensible system attributes can be viewed through two special > extended attribute files: SUNWattr_ro and SUNWattr_rw. > > Sections 4.1 and 4.1.1 describe the views and the attributes > available through each. > 3.2 BSD/MacOS X Attributes 95,96c122,123 < attributes requires PRIV_FILE_FLAG_SET. Clearing the attribute < requires a process to have PRIV_FILE_FLAG_CLEAR --- > attributes requires PRIV_FILE_FLAG_SET. Clearing these attributes > requires ALL privileges. 108,110c135,137 < modified. Also prevents all metadata changes, except for < access time updates. When placed on a directory the attribute < will prevent the deletion and creation of files and --- > modified or deleted. Also prevents all metadata changes, except > for access time updates. When placed on a directory the > attribute will prevent the deletion and creation of files and 3.3 Third-Party Requested Attributes 126,129c153,156 < porting ZFS to a different platform. Solaris will not set these < attributes nor will there be any sematics associated with them. < Callers will be permitted to read the attributes. Attempts to set < these attributes will fail with EPERM. --- > porting ZFS to a different platform. Solaris will not have any > semantics associated with them at this time. Callers will be > permitted to read the attributes. Modifications to the attributes > are described below. 132a160,161 > Modification of NODUMP requires PRIV_FILE_FLAG_SET to set it > and ALL privileges to clear it. 135a165 > Attempts to set this will fail with EPERM. 138a169 > Attempts to set this will fail with EPERM. 4.0 INTERFACES 153c184 < At the application layer, system attributes are retrieved and --- > At the application layer, the standard attributes are retrieved and 4.1 Extensions to Extended Attribute Interface for System Attributes 202,204c233,235 < Any filesystem object, including extended attributes, may have system < attributes. The exception is that recursive system attributes < (sysattrs on sysattrs) are not allowed. --- > Any regular file, directory, or opaque extended attribute file, may > have system attributes. Recursive system attributes (sysattrs on > sysattrs) are not allowed. 218,219c249,250 < Filesystems may support any combination of system and regular < extended attributes. --- > Filesystems may support any combination of extensible system > attributes and regular extended attributes. 222c253 < extended attribute namespace of all regular files: --- > extended attribute namespace of all regular files and directories: 247c278 < namespace of a regular file will fail with EINVAL. Any attempt to --- > namespace of a file will fail with EINVAL. Any attempt to 267a299,300 > Writes to the SUNWattr_rw will have no effect on any system attributes > not contained in the nvlist. 4.2.1 New Interfaces for System Attributes 340c373 < attribute associated with each regular file. The current list --- > attribute associated with each file. The current list 4.3.1 NFSv4 Support for Optional Attributes (Potential Future Work) 734,738c767,771 < In fact, two of the new attributes (ARCHIVE and HIDDEN) are part of < the "recommended" list of attributes for a client and server < implementation. The Solaris NFSv4 client and server could be < modified to support the new, optional attributes as specified by < the protocol. --- > In fact, four of the new attributes (ARCHIVE, HIDDEN, SYSTEM, and > CREATETIME) are part of the "recommended" list of attributes for a > client and server implementation. The Solaris NFSv4 client and > server could be modified to support the new, optional attributes as > specified by the protocol. --Boundary_(ID_SQ3sL0mXWKpDMaZs2ikZdA) Content-type: text/plain; name=sysattrs-spec-3.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=sysattrs-spec-3.txt 1.0 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 Although each of these changes is 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. The project team requests MINOR binding. 2.0 OVERVIEW The Solaris CIFS project requires file system support for a number of new "system" attributes. For file systems that fully support CIFS, the system attributes will be present on all regular files, directories, and opaque extended attribute files. The file system will need to update the attribute(s) as a result of various file system operations such as data written to a file. The CIFS server and application programs will also need to be able to query/update the attributes when needed. Additionally, the CIFS server will be using the Solaris extended attribute model for storing a number of opaque file attributes. ZFS will be the primary underlying file system for the CIFS server. In order to accommodate the existing extended attribute aware utilities in Solaris, the new attributes will be exposed as "views" via the existing Solaris extended attribute model. The new attributes will be grouped in a number of SUNWattr* files that will have multiple attributes in a single file composed as an XDR packed nvlist. Section 4.1 and 4.2 will describe the interfaces for manipulating system attributes and how they are exposed as Solaris extended attributes. It's important to note that there are three distinct types of file attributes being discussed: - Standard file attributes are the file attributes that are returned with the stat(2) system call. - Extended attributes as described by PSARC 1999/209 Extended File Attributes. - Extensible system attributes as described by this case. There are two specific, intentional areas where the interfaces that deal with extensible system attributes overlap with the other two types: * Standard file attributes and the extensible system attributes are retrieved and set using VOP_GETATTR() and VOP_SETATTR() respectively. Section 4.3 of the spec describes these interfaces and their extensions. * Extensible system attributes can be viewed through two special extended attribute files: SUNWattr_ro and SUNWattr_rw. Sections 4.1 and 4.1.1 describe the views and the attributes available through each. 3.0 NEW SYSTEM ATTRIBUTES REQUIRED 3.1 DOS Attributes The CIFS server requires the file system to support the old "DOS" attributes. These attributes can be set/cleared by the owner of a file or a user/group that has been granted the permission via the "write_attributes" ACE permission. CREATETIME The timestamp when a file is created. The owner of the file or any user with "write_attributes" permission has the ability modify this value to any time. ARCHIVE Attribute used to indicate if a file has been modified since it was last backed up. Whenever the modification time (mtime) of a file is changed the "archive" attribute will be set. READONLY Attribute to mark a file as readonly. Once a file is marked as readonly the content data of the file cannot be modified. Other metadata for the file can still be modified. This attribute can be set on directories but it has no semantic meaning. All attempts to modify the content of the file will return EPERM. HIDDEN Attribute to mark a file as hidden. Solaris allows the attribute to be set but it only has meaning in the context of a CIFS server. SYSTEM Solaris has no special semantics for this attribute, but it can be set/cleared with appropriate privilege. 3.2 BSD/MacOS X Attributes In order to ease the porting of ZFS to BSD and MacOS X the following "system" attributes will be supported in ZFS. Setting these attributes requires PRIV_FILE_FLAG_SET. Clearing these attributes requires ALL privileges. NOUNLINK Attribute that prevents a file from being deleted. On a directory, the attribute will also prevent any changes to the contents of the directory. That is, no files within the directory can be removed or renamed. The errno EPERM will be returned when attempting to unlink or rename files and directories that are marked as NOUNLINK. IMMUTABLE Attribute used to prevent the content of a file from being modified or deleted. Also prevents all metadata changes, except for access time updates. When placed on a directory the attribute will prevent the deletion and creation of files and directories. Attempts to modify the content of a file or directory marked as IMMUTABLE will fail with EPERM being returned. Attempts to modify any attributes (with the exception of access time and, with the proper privleges, the IMMUTABLE attribute) of a file marked as IMMUTABLE will fail with EPERM. APPENDONLY Used to allow a file to be modified only at offset EOF. Attempts to modify a file at a location other than EOF will fail with EPERM. 3.3 Third-Party Requested Attributes The following attributes have been requested by a third-party vendor porting ZFS to a different platform. Solaris will not have any semantics associated with them at this time. Callers will be permitted to read the attributes. Modifications to the attributes are described below. NODUMP Solaris has no special semantics for this attribute. Modification of NODUMP requires PRIV_FILE_FLAG_SET to set it and ALL privileges to clear it. SETTABLE Solaris has no special semantics for this attribute. Attempts to set this will fail with EPERM. OPAQUE Solaris has no special semantics for this attribute. Attempts to set this will fail with EPERM. 3.4 Anti-Virus attributes AV_QUARANTINED Set by anti-virus software to mark a file as quarantined. See PSARC/2007/118 for more details on the Virus Scan case. AV_MODIFIED Anti-virus attribute which ZFS will set whenever a file's content or size changes or when the file is renamed. See PSARC/2007/118 for more detail on the Virus Scan case. 4.0 INTERFACES At the application layer, the standard attributes are retrieved and modified by a variety of system calls (e.g., stat(2), chmod(2), chgrp(2), utimes(2)). The system call interface uses a vattr_t structure in conjunction with the VOP_GETATTR() and VOP_SETATTR() file system interfaces to retrieve and modify attributes at the kernel level. These interfaces are efficient but are limited to a fixed set of attributes. The CIFS server project requires a new set of system level attributes and file system support for their semantics. To make matters more interesting, these new attributes are not required for all file systems. The challenge is to maintain support for the existing interfaces and provide support for these new, optional attributes. This case proposes a set of solutions that: - Introduce new libc interfaces to allow applications to manipulate the optional attributes. The new libc interfaces will utilize nvlist/nvpairs to request the attributes an application is interested in. The attribute data will be returned in an nvlist. The nvlists are used so that we will have the ability to easily extend the list of attributes an application can manipulate. The new libc interfaces will be built on top of the extended attribute mechanism as described below. - Enhance the file system extended attribute interface to support system attributes. Support will be added for readonly system attributes as well as read-write system attributes. - Extend the standard Solaris vattr_t to allow additional, optional attributes to be set/retrieved as part of the standard VOP_GETATTR() and VOP_SETATTR() interface. 4.1 Extensions to Extended Attribute Interface for System Attributes One of the challenges of integrating optional system attributes into Solaris is the issue of support from the file management utilities such as mv, cp, tar, cpio, etc. The solution is to augment the existing extended attribute interface to handle system attributes. The file management utilities already support extended attributes so this solution enables these utilities to support system attributes without large modifications. Using this interface also centralizes attribute management and simplifies future changes to the attribute space as discussed in Section 4.4. For more on utilities, see section 4.5 "Changes to Utilities". Any regular file, directory, or opaque extended attribute file, may have system attributes. Recursive system attributes (sysattrs on sysattrs) are not allowed. For every filesystem object that supports system attributes, the reserved system attribute names will always appear to exist. However, these names will be virtual and should not exist in an on-disk directory structure. No on-disk extended attribute directory will be created until the first creation of a regular extended attribute on that object. For filesystem objects that have other non-system attributes, the set of system attribute names will be concatenated with the set of non-system attribute names so that they appear to comprise a single coherent directory. Filesystems may support any combination of extensible system attributes and regular extended attributes. The following files will be added to the top level directory in the extended attribute namespace of all regular files and directories: -r--r--r-- 1 root root 88 May 16 16:17 SUNWattr_ro -rw-r--r-- 1 root root 484 May 16 16:17 SUNWattr_rw Instead of exposing each individual system attribute as a named object, we are exposing named sets of system attributes as views into the system attribute space. This is being done to minimize clutter in the name space. The XATTR_VIEW_READONLY view contains only the readonly system attributes. The XATTR_VIEW_READWRITE view contains all of the read/write system attributes. Section 4.1.1 lists the attributes and data types for each view. The file SUNWattr_ro corresponds to the XATTR_VIEW_READONLY view. The file SUNWattr_rw corresponds to the XATTR_VIEW_READWRITE view. The size of each file is the size of the nvlist for the attributes associated with that file/view. The supported views, attributes, and data types for each view are defined in the header file /usr/include/sys/attr.h. Any attempt to create a file or directory named SUNWattr_ro or SUNWattr_rw in the top level directory in the extended attribute namespace of a file will fail with EINVAL. Any attempt to remove either the SUNWattr_ro or the SUNWattr_rw file will fail with EACCES. Attempts to rename SUNWattr_ro or SUNWattr_rw will fail with EINVAL. Attempts to open the SUNWattr_ro file for write will fail with EACCES. Any attempt to read a different number of bytes than the size of the SUNWattr_ro or the SUNWattr_rw file will return the lesser of: The number of bytes requested or the number of bytes in the file. If the number of bytes returned is less that the number of bytes in the file then the data will not likely be a valid nvlist. The expected usage for an application is call stat() or fstat() to determine the size of the buffer that must be provided to read(). The new libc interfaces described in 4.2.1 are implemented this way. All writes to the SUNWattr_rw file that do not contain a valid nvlist will fail with EINVAL. A valid nvlist must contain only valid nvpairs for one or more attributes associated with that file/view. Writes to the SUNWattr_rw will have no effect on any system attributes not contained in the nvlist. Note that since the Solaris NFSv3/v4 clients and servers are already aware of the Solaris extended attribute interface, file management utilities (mv, cp, cpio, tar, etc) will work over NFS in a Solaris environment as described above. This does not imply protocol support for individual attributes. This is simply stating that the SUNWattr_rw and SUNWattr_ro files can both be read and SUNWattr_rw can be written over NFS on Solaris. (See section 4.3.1 for more on NFSv4 protocol support.) 4.1.1 Supported views and the attributes and data types for each view: View Attribute Data type XATTR_VIEW_READONLY A_FSID uint64_t A_MDEV uint16_t XATTR_VIEW_READWRITE A_READONLY boolean_value A_HIDDEN boolean_value A_SYSTEM boolean_value A_ARCHIVE boolean_value A_CRTIME uint64_array[2] A_NOUNLINK boolean_value A_IMMUTABLE boolean_value A_APPENDONLY boolean_value A_NODUMP boolean_value A_SETTABLE boolean_value A_OPAQUE boolean_value A_AV_QUARANTINED boolean_value A_AV_MODIFIED boolean_value A_OWNERSID nvlist_t *** A_GROUPSID nvlist_t *** *** The nvlist_t values are composed of uint32_t types and strings NOTES: A_FSID and A_MDEV represent the file system ID and the mounted device, respectively. Those values are determined at mount time and cannot be set by an application. The A_OWNERSID, A_GROUPSID represent the CIFS owner and group, respectively, and will only be returned if they exist. 4.2 User-Level API for Optional System Attributes The following sections describe the new interfaces to support system attributes and a discussion of the utility changes necessary. 4.2.1 New Interfaces for System Attributes The following interfaces will be added to libc. A manual page that describes these interfaces has been added to the case directory. Applications that wish to retrieve or modify system attributes should include the new header file /usr/include/attr.h which defines the interfaces below. int fgetattr(int fildes, xattr_view_t view, nvlist_t **response); int fsetattr(int fildes, xattr_view_t view, nvlist_t *request); int getattrat(int fildes, xattr_view_t view, const char *filename, nvlist_t **response); int setattrat(int fildes, xattr_view_t view, const char *filename, nvlist_t *request); Where: 'fildes' must be an open file descriptor associated with the file object from which system attributes will be obtained or updated. 'view' must be one of the supported "views" into the system attribute associated with each file. The current list of supported views is XATTR_VIEW_READONLY and XATTR_VIEW_READWRITE. Additional views may be added in the future 'filename' must be a file in the extended attribute directory associated with fildes. getattrat() will obtain system attributes from filename and setattrat() will update the system attributes for filename 'response' must be the address of a pointer to an nvlist which will contain one nvpair for each of the system attributes associated with view 'request' must be a pointer to an nvlist containing one or more nvpairs of system attributes associated with view fgetattr() obtains an nvlist of system attribute information about the file associated with the provided open file descriptor. getattrat() obtains an nvlist of system attributes information about the extended attribute file with the provided filename in the extended attribute directory associated with the provided open file descriptor. Upon successful completion, the nvlist will contain one nvpair for each of the system attributes associated with the provided view. The current list of supported views is XATTR_VIEW_READONLY and XATTR_VIEW_READWRITE. Not all filesystems support all views and all attributes. The nvlist will not contain an nvpair for any view or attribute not supported by the underlying filesystem. fsetattr() uses the provided nvlist to update one or more of the system attributes of the file associated with the provided open file descriptor. setattrat() uses the provided nvlist to update one or more of the system attributes of the extended attribute file with the provided filename in the extended attribute directory associated with the provided open file descriptor. If completion is not successful then no system attribute information is updated. For more info on these APIs see the man page in the case directory. 4.2.2 Changes for pathconf(2) Retrieving the pathconf variable _PC_XATTR_EXISTS on a filesystem object currently returns 1 if the object has any extended attributes. For filesystems that support system attributes, every filesystem object will implicitly have extended attributes. In order for this pathconf to remain useful, _PC_XATTR_EXISTS will now return 1 if and only if the object has real (non-system) extended attributes. Two new pathconf variables will be added: _PC_SATTR_ENABLED is similar to _PC_XATTR_ENABLED in that its value will be 1 if the object supports system attributes. Unlike _PC_XATTR_ENABLED, this is not necessarily enforced at VFS granularity. Filesystems may choose not to support system attributes for certain object types (e.g. .zfs). _PC_SATTR_EXISTS has the same semantics as _PC_SATTR_ENABLED and is being provided only for similarity to the extended attribute pathconf calls. 4.3 Extensible vattr_t for VOP_GETATTR()/VOP_SETATTR() The CIFS server requires several new file attributes to be added to ZFS to support Windows (CIFS) clients. These attributes are required on file systems that fully support CIFS, but are not required in general. They are considered to be optional attributes and aren't required to be supported on every file system. In order to support new, optional attributes, Solaris needs a fast, flexible attribute interface at the VOP level that can set and retrieve both standard and optional attributes. This interface must take into account the fact that the underlying file system may choose not to support those attributes. In addition, the interfaces must allow new, optional attributes to be added with minimal disruption of the existing interfaces. Ideally, attributes can be added in a patch or update release without affecting unbundled file systems. The following proposes an extensible structure that can be used with the existing VOP_SETATTR/VOP_GETATTR interface to set/retrieve both required and optional system attributes. This structure can also be used by VOP_MKDIR() and VOP_CREATE() in place of their existing vattr_t pointer to set optional attributes at create time. This new structure, xvattr_t, contains the following: - the existing vattr_t structure (embedded) as the first member - two counted arrays of 32 bit words each of which represents an extensible bitmap of optional attributes. The first bitmap represents the requested attributes. The second represents the returned attributes. That is, the attributes that the file system was able to process. - a structure of values for the optional file attributes - additional fields to support extensibility In vnode.h, we have the existing bit mask values which are used in the va_mask field of the existing vattr_t structure: /* * Attributes of interest to the caller of setattr or getattr. */ #define AT_TYPE 0x0001 #define AT_MODE 0x0002 #define AT_UID 0x0004 ... #define AT_SEQ 0x8000 #define AT_ALL (AT_TYPE|AT_MODE|AT_UID| ... |AT_SEQ) We now add: #define AT_XVATTR 0x10000 /* Optional attributes present */ Which indicates that the structure contains optional attributes set in the bitmap array. Note that we do *not* add AT_XVATTR to the AT_ALL #define. The callers who desire optional attributes will be required to set/check AT_XVATTR explicitly. This allows callers to use existing code without modification. The definition of xvattr_t is: typedef struct xvattr { vattr_t xva_vattr; /* Embedded vattr structure */ uint32_t xva_magic; /* Magic Number */ uint32_t xva_mapsize; /* Size of attr bitmaps */ uint32_t *xva_rtnattrmapp; /* Ptr to xva_rtnattrmap[] */ uint32_t xva_reqattrmap[XVA_MAPSIZE]; /* Requested attrs */ uint32_t xva_rtnattrmap[XVA_MAPSIZE]; /* Returned attrs */ xoptattr_t xva_xoptattrs; /* Optional attributes */ } xvattr_t; The fields of the xvattr structure are as follows: xva_vattr - The first element of an xvattr is an embedded legacy vattr structure which includes the common attributes. If AT_XVATTR is set in the va_mask (member of vattr_t) then the entire structure is treated as an xvattr_t. If AT_XVATTR is not set, then only the xva_vattr structure can be used. xva_magic - 0x78766174 (hex for "xvat"). Magic number for verification set by xva_init(). xva_mapsize - Size of requested and returned attribute bitmaps. This is initialized to XVA_MAPSIZE by xva_init(). xva_rtnattrmapp - Pointer to xva_rtnattrmap[]. In an update/patch, the size of xva_reqattrmap[] could change which means the location of xva_rtnattrmap[] could change. This will allow unbundled file systems to reliably locate the xva_rtnattrmap[] if the size of the attribute bitmaps change. This value is initialized by the xva_init() routine. xva_reqattrmap[] - Array of requested attributes. Each attribute is represented by a specific bit in a specific element of the attribute map array. Callers set the bits corresponding to the attributes that the caller wants to get/set. xva_rtnattrmap[] - Array of attributes that the file system was able to process. Not all file systems support all optional attributes. This map informs the caller which attributes the underlying file system was able to set/get. (Same structure as the requested attributes array in terms of each attribute corresponding to a specific bit and in a specific array elements.) xva_xoptattrs - Structure containing values of optional attributes. For VOP_SETATTR(), these values are only valid to the file system if AT_XVATTR is set in the va_mask and the corresponding bits in xva_reqattrmap are set. Upon return from VOP_GETATTR(), these values are only valid if AT_XVATTR is set in the va_mask and the corresponding bits in xva_rtnattrmap are set (indicating that the underlying file system supports those attributes.) The optattr_t structure consists of all optional attributes (described above): typedef struct xoptattr { timestruc_t xoa_createtime; uint8_t xoa_archive; uint8_t xoa_system; uint8_t xoa_readonly; uint8_t xoa_hidden; uint8_t xoa_nounlink; uint8_t xoa_immutable; uint8_t xoa_appendonly; uint8_t xoa_nodump; uint8_t xoa_settable; uint8_t xoa_opaque; uint8_t xoa_av_quarantined; uint8_t xoa_av_modified; } xoptattr_t; The attribute map arrays, xva_reqattrmap[] and rtnattrmap[], are used as follows: Each element of the bitmap array is represented as a 32 bit word. The member xva_mapsize determines the number of elements in the bitmap arrays. (Both xva_reqattrmap[] and rtnattrmap[] have the same length.) element 0: 0 bit represents first attribute, bit n is the n+1th attribute element 1: 0 bit represents 33rd attribute (assuming 32 bit masks), bit m is the 33+mth attribute ...and so on. Each attribute is represented by a specific bit in a specific array element of the attribute bitmaps. To this end, the position of each attribute in the bitmap is represented by a 64 bit word: The most significant 32 bits represents the index into the bitmaps, the least significant bits contains the bit corresponding to this attribute. The attributes are represented numerically as follows: INDEX BIT XAT_CREATETIME 0x00000000 00000001 XAT_ARCHIVE 0x00000000 00000002 XAT_SYSTEM 0x00000000 00000004 XAT_READONLY 0x00000000 00000008 XAT_HIDDEN 0x00000000 00000010 XAT_NOUNLINK 0x00000000 00000020 XAT_IMMUTABLE 0x00000000 00000040 XAT_APPENDONLY 0x00000000 00000080 XAT_NODUMP 0x00000000 00000100 XAT_SETTABLE 0x00000000 00000200 XAT_OPAQUE 0x00000000 00000400 XAT_AV_QUARANTINED 0x00000000 00000800 XAT_AV_MODIFIED 0x00000000 00001000 For example, the representation in the bitmaps for the "hidden" attribute is the 0th element, bit 0x10. In the header file, these are represented by specific #defines which detail the individual bits and the manipulation necessary to represent the index. (See below) For the #defines representing the individual bits, convention is to use XAT{n}_{attrname} where "n" is the element in the bitmap (starting at 0). This convention is for the convenience of the maintainer to keep track of which element each attribute belongs to. The bitmap array index for the group is also defined so that the full representation (see below) can be built. Callers are strongly discouraged from using the XAT{n}_* #defines but providers (e.g., file systems) may choose to use these for performance reasons. #define XAT0_CREATETIME 0x00000001 /* Create time of file */ #define XAT0_ARCHIVE 0x00000002 /* Archive */ #define XAT0_SYSTEM 0x00000004 /* System */ #define XAT0_READONLY 0x00000008 /* Readonly */ #define XAT0_HIDDEN 0x00000010 /* Hidden */ #define XAT0_NOUNLINK 0x00000020 /* Nounlink */ #define XAT0_IMMUTABLE 0x00000040 /* immutable */ #define XAT0_APPENDONLY 0x00000080 /* appendonly */ #define XAT0_NODUMP 0x00000100 /* nodump */ #define XAT0_SETTABLE 0x00000200 /* settable */ #define XAT0_OPAQUE 0x00000400 /* opaque */ #define XAT0_AV_QUARANTINED 0x00000800 /* anti-virus quarantine */ #define XAT0_AV_MODIFIED 0x00001000 /* anti-virus modified */ The following defines present a "flat namespace" so that consumers don't need to keep track of which element belongs to which bitmap entry. #define XAT0_INDEX 0LL /* Index into bitmap for XAT0 attrs */ #define XVA_SHFT 32 /* Used to shift index */ #define XAT_CREATETIME ((XAT0_INDEX << XVA_SHFT) | XAT0_CREATETIME) #define XAT_ARCHIVE ((XAT0_INDEX << XVA_SHFT) | XAT0_ARCHIVE) #define XAT_SYSTEM ((XAT0_INDEX << XVA_SHFT) | XAT0_SYSTEM) #define XAT_READONLY ((XAT0_INDEX << XVA_SHFT) | XAT0_READONLY) #define XAT_HIDDEN ((XAT0_INDEX << XVA_SHFT) | XAT0_HIDDEN) #define XAT_NOUNLINK ((XAT0_INDEX << XVA_SHFT) | XAT0_NOUNLINK) #define XAT_IMMUTABLE ((XAT0_INDEX << XVA_SHFT) | XAT0_IMMUTABLE) #define XAT_APPENDONLY ((XAT0_INDEX << XVA_SHFT) | XAT0_APPENDONLY) #define XAT_NODUMP ((XAT0_INDEX << XVA_SHFT) | XAT0_NODUMP) #define XAT_SETTABLE ((XAT0_INDEX << XVA_SHFT) | XAT0_SETTABLE) #define XAT_OPAQUE ((XAT0_INDEX << XVA_SHFT) | XAT0_OPAQUE) #define XAT_AV_QUARANTINED ((XAT0_INDEX << XVA_SHFT) | XAT0_AV_QUARANTINED) #define XAT_AV_MODIFIED ((XAT0_INDEX << XVA_SHFT) | XAT0_AV_MODIFIED) The following routines and macros are provided for the convenience of both callers and providers (e.g., file systems). void xva_init(xvattr_t *xvap); * Initializes the xvattr structure pointed to by xvap. It zeros the structure, sets the size of the bitmaps, initializes the "magic" number, and sets the xva_rtnattrmapp pointer. xoptattr_t *xva_getxoptattr(xvattr_t *xvap); * If the structure pointed to by xvap is an xvattr_t (AT_XVATTR is set in the xva_vattr's va_mask, XVA_MAGIC is set in xva_magic), then return a pointer to the xva_xoptattr structure. Otherwise, return NULL. XVA_SET_REQ(xvap, attr) * Sets an attribute bit in the proper element in the bitmap of requested attributes (xva_reqattrmap[]). XVA_SET_RTN(xvap, attr) * Sets an attribute bit in the proper element in the bitmap of returned attributes (xva_rtnattrmap[]). XVA_ISSET_REQ(xvap, attr) * Checks the requested attribute bitmap (xva_reqattrmap[]) to see of the corresponding attribute bit is set. If so, returns non-zero. XVA_ISSET_RTN(xvap, attr) * Checks the returned attribute bitmap (xva_rtnattrmap[]) to see of the corresponding attribute bit is set. If so, returns non-zero. Consumers and file systems that use these accessor routines are protected against changes in the size of the attribute bitmap arrays. This allows new attributes to be added in a patch/update without affecting unbundled file systems. The following describes how a caller can retrieve and set optional attributes using the xvattr_t structure: - The caller uses xva_init() to initialize the xvattr_t structure. Among other things, this zeros the structure and sets the size of the attribute bitmap arrays. - The caller uses the XVA_SET_REQ() macro to set individual attribute bits in the xva_reqattrmap[] array. - For retrieving attributes, the xva_xoptattrs field has already been cleared in xva_init() so the caller simply passes a pointer to the xvattr_t structure to VOP_GETATTR(). - For setting attributes, the caller sets the corresponding values in the xva_xoptattrs field then passes a pointer to the xvattr_t structure to VOP_SETATTR(). - On a successful return from VOP_GETATTR/VOP_SETATTR: * The caller checks the va_mask of xva_vattr to see if AT_XVATTR is set. This bit will be cleared in fop_getattr()/fop_setattr() if the underlying file system does not support optional attributes. If the AT_XVATTR bit is not set, then the underlying file system was unable to process the optional attributes. * If AT_XVATTR was set, then the caller uses XVA_ISSET_RTN() on each attribute to see if the file system processed the attribute. For any attribute bit that was not set, the attribute value was not processed. In the case of VOP_GETATTR(), it means that the corresponding value in the xva_xoptattrs field is invalid. In the case of VOP_SETATTR(), it means that the value was not set. * For retrieving attributes, the value of the corresponding attribute is found in the xva_xoptattrs structure. Existing callers and file systems that do not participate in the new attributes do not need to change. They simply manipulate and access the vattr_t passed to VOP_GETATTR()/VOP_SETATTR() as before. A new VFS Feature (PSARC 2007/227) is being added to indicate that a file system supports xvattr_t and the AT_XVATTR bit: VFSFT_XVATTR. The fop_getattr() and fop_setattr() routines will query for this feature. If this feature is not present, then the fop routines will clear the AT_XVATTR bit from the va_mask field of the (x)vattr_t. Kernel modules can also query for this VFS Feature to determine if a file system supports optional attributes (xvattr_t/AT_XVATTR). 4.3.1 NFSv4 Support for Optional Attributes (Potential Future Work) The NFSv4 protocol has an attribute model that supports extensions. In fact, four of the new attributes (ARCHIVE, HIDDEN, SYSTEM, and CREATETIME) are part of the "recommended" list of attributes for a client and server implementation. The Solaris NFSv4 client and server could be modified to support the new, optional attributes as specified by the protocol. This work is not currently funded. 4.4 Managing Change in the Attribute Space The issue of adding new attributes and the semantics of those attributes need to be discussed in an opensolaris community dedicated to file system framework issues. There is a proposal in the opensolaris governing board to reorganize (among other things) the file system area. The project team will work with the governing board to determine the appropriate forum to discuss general file system issues. In the meantime, we ask that the ARC work with project teams to ensure new proposals for attributes, their names, and their semantics are reasonable. Members of this project team will be monitoring both the opensolaris and PSARC aliases for related projects. Until an opensolaris community is up and running, project teams and PSARC are welcome to forward attribute-related questions to fs-framework@sun.com . 4.5 Changes to Utilities The project team is aware of an impact to the following utilities: ls, tar, cpio, pax, cp, mv, pack, unpack, pcat, etc. These utilities will need to handle a new option flag (similar to "-@") to specify archive/restore of sysattrs. Since _PC_XATTR_EXISTS will return 0 for file system objects that only have system attributes (and no regular extended attributes), these utilities will need to call _PC_SATTR_EXISTS to determine the correct handling of system attributes. The utilities team will be submitting fast-tracks to address these changes in detail. 5.0 EXPORTED INTERFACE TABLE |Proposed |Specified | |Stability |in what | Interface Name |Classification |Document? | Comments =============================================================================== |Consolidation |This | |Private |Document | | | | SUNWattr_ro | | | Read-only view of | | | extended attribute | | | namespace | | | SUNWattr_rw | | | Read-write view of | | | extended attribute | | | namespace | | | A_FSID, A_MDEV | | | Contents of read-only | | | view of extended | | | attribute namespace | | | A_READONLY, A_HIDDEN, | | | Contents of A_SYSTEM, A_ARCHIVE, | | | read-write view of A_CRTIME, A_NOUNLINK, | | | extended attribute A_IMMUTABLE, A_NODUMP | | | namespace A_APPENDONLY, A_OPAQUE,| | | A_AV_QUARANTINED, | | | A_AV_MODIFIED, | | | A_OWNERSID, A_GROUPSID | | | | | | _PC_SATTR_ENABLED | | | New pathconf(2) _PC_SATTR_EXISTS | | | variables | | | struct xvattr | | | Extensible version xvattr_t | | | of vattr_t | | | AT_XVATTR | | | New flag for the | | | va_mask of vattr_t | | | struct xoptattr | | | New structure to hold xoptattr_t | | | values of optional | | | system attributes | | | XAT_CREATETIME | | | Values for new XAT_ARCHIVE | | | system attributes XAT_SYSTEM | | | to be used with XAT_READONLY | | | XVA_SET_*() and XAT_HIDDEN | | | XVA_ISSET_*() macros XAT_NOUNLINK | | | XAT_IMMUTABLE | | | XAT_APPENDONLY | | | XAT_NODUMP | | | XAT_SETTABLE | | | XAT_OPAQUE | | | XAT_AV_QUARANTINED | | | XAT_AV_MODIFIED | | | | | | xva_init() | | | Initialization for | | | xvattr_t structure | | | xva_getxoptattr() | | | Retrieves pointer to | | | xoptattr_t, if it is | | | available | | | XVA_SET_REQ() | | | Sets the appropriate XVA_SET_RET() | | | attribute bit in the | | | request or return | | | bitmap. | | | XVA_ISSET_REQ() | | | Checks the appropriate XVA_ISSET_RET() | | | attribute bit in the | | | request or return | | | bitmap. | | | VFSFT_XVATTR | | | VFS feature to be | | | registered by an FS | | | with xvattr_t support | | | fgetattr() | | This document | New interfaces in fsetattr() | | and the man | libc for retrieving getattrat() | | page for | and modifying system setattrat() | | fgetattr(3c) | attributes in the | | | extended attribute | | | /usr/include/attr.h | Committed | This document | Defines libc APIs | | | described in section | | | 4.2.1 | | | /usr/include/sys/attr.h| | | Defines views and | | | attribute names for | | | nvlists --Boundary_(ID_SQ3sL0mXWKpDMaZs2ikZdA)-- From Timothy.Haley@Sun.COM Wed Jun 13 10:32:34 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 l5DHWY67017141 for ; Wed, 13 Jun 2007 10:32:34 -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 l5DHUZ6i049288 for <@sunmail3mpk.sfbay.sun.com:psarc-ext@sun.com>; Wed, 13 Jun 2007 11:30:36 -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 <0JJL0090L4NQKW00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Jun 2007 10:31:02 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JJL000SH4NPB2E0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Jun 2007 10:31:01 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5DHV15T005220 for ; Wed, 13 Jun 2007 17:31:01 +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 <0JJL00G014MMQP00@mail-amer.sun.com> (original mail from Timothy.Haley@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Jun 2007 11:31:01 -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 <0JJL00MUD4NMFVQ0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 13 Jun 2007 11:31:00 -0600 (MDT) Date: Wed, 13 Jun 2007 11:30:42 -0600 From: Tim Haley Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <200705301919.l4UJJJKE004851@spidey.central.sun.com> Sender: Timothy.Haley@Sun.COM To: psarc-ext@Sun.COM Message-id: <467029C2.6070108@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: <200705301919.l4UJJJKE004851@spidey.central.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070521) Status: RO Content-Length: 157 Timothy Haley - Sun Microsystem wrote: > Extensible Attribute Interfaces [PSARC/2007/315 FastTrack] This case was approved at today's PSARC meeting. -tim From schilling@fokus.fraunhofer.de Fri Jun 15 07:31:05 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 l5FEV5sP025571 for ; Fri, 15 Jun 2007 07:31:05 -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 l5FETTFw003986; Fri, 15 Jun 2007 07:29:29 -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 <0JJO00519LL5N400@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jun 2007 07:29:29 -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 <0JJO00C5FLL37SA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jun 2007 07:29:27 -0700 (PDT) Received: from relay1.sun.com (relay1.sun.com [150.143.103.14] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5FDeXQ4018625; Fri, 15 Jun 2007 14:29:27 +0000 (GMT) Received: from mms02es.sun.com ([150.143.104.34] [150.143.104.34]) by relay1.sun.com with ESMTP id BT-MMP-126742; Fri, 15 Jun 2007 14:29:27 +0000 (Z) Received: from relay01i.sun.com (ip70.net150143-60.block3.us.syntegra.com [150.143.60.70]) by mms02es.sun.com with ESMTP id BT-MMP-998130; Fri, 15 Jun 2007 14:29:27 +0000 (Z) Received: from relay44i.sun.com ([192.5.209.118] [192.5.209.118]) by relay0i.sun.com with ESMTP id BT-MMP-840413; Fri, 15 Jun 2007 14:29:27 +0000 (Z) Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14] [193.174.154.14]) by relay4i.sun.com with ESMTP id BT-MMP-978537; Fri, 15 Jun 2007 14:29:26 +0000 (Z) Received: from burner.fokus.fraunhofer.de (burner [10.147.65.166]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id l5FETOP02645; Fri, 15 Jun 2007 16:29:24 +0200 (MEST) Received: (from jes@localhost) by burner.fokus.fraunhofer.de (8.12.9+Sun/8.12.9/Submit) id l5FERju3008975; Fri, 15 Jun 2007 16:27:45 +0200 (CEST) Date: Fri, 15 Jun 2007 16:27:45 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout 06/06/2007] In-reply-to: <465EA38D.6000704@Sun.COM> Sender: schilling@fokus.fraunhofer.de To: timh@spidey.central.sun.com, Darren.Moffat@Sun.COM Cc: Richard.Morris@Sun.COM, PSARC-ext@Sun.COM, Mark.Shellenbaum@Sun.COM, Mark.Maybee@Sun.COM, cifs-vfs-team@Sun.COM, Christopher.Kirby@Sun.COM Message-id: <4672a1e1.jEx7Ok/CL/+YOTGH%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.2.0.264296 References: <200705301919.l4UJJJKE004851@spidey.central.sun.com> <465EA38D.6000704@Sun.COM> User-Agent: nail 11.22 3/20/05 Status: RO Content-Length: 1158 Darren J Moffat wrote: > Timothy Haley - Sun Microsystem wrote: > > 3.3 Third-Party Requested Attributes > > > > The following attributes have been requested by a third-party vendor > > porting ZFS to a different platform. Solaris will not set these > > attributes nor will there be any sematics associated with them. > > Callers will be permitted to read the attributes. Attempts to set > > these attributes will fail with EPERM. > > > > NODUMP > > Solaris has no special semantics for this attribute. > > This one seems useful on Solaris. Assuming the name is reflective of > its purpose it says to me that files with this attribute should not be > included in backups. For example tar/cpio/pax might pay attention to > that attribute but 'zfs send' would not. Star does pay attention to this flag since 2001 Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily