From owner-nfsv4-wg@sunroof.eng.sun.com Mon Feb 3 11:29:19 2003 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12320 for ; Mon, 3 Feb 2003 11:29:18 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28129; Mon, 3 Feb 2003 09:28:16 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13GRNVL018128; Mon, 3 Feb 2003 08:27:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13GRBQb006639 for ; Mon, 3 Feb 2003 08:27:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h13GRBeS006637 for nfsv4-wg-dist; Mon, 3 Feb 2003 08:27:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h13GR9Qb006630 for ; Mon, 3 Feb 2003 08:27:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h13GRIVL018092 for ; Mon, 3 Feb 2003 08:27:18 -0800 (PST) Received: from malmo.trab.se (malmo.kicore.net [131.115.48.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03171; Mon, 3 Feb 2003 09:27:10 -0700 (MST) Received: from terra (terra.malmo.kicore.net [217.212.0.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id h13GR7n13942; Mon, 3 Feb 2003 17:27:08 +0100 (MET) Message-Id: <200302031627.h13GR7n13942@malmo.trab.se> Date: Mon, 3 Feb 2003 17:29:58 +0100 (CET) From: Dan Oscarsson Reply-To: Dan Oscarsson Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] To: Nicolas.Williams@sun.com Cc: nfsv4-wg@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HvqdzlXFkBDfRVdosOPw3A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 sun4u sparc Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 2339 Lines: 58 >happy (my security instincts say that nonetheless the server should >enforce a normalization form, but I can't yet find a convincing security >argument). Well, as many programs will not check for unnormalised or different normalisations and instead expect the code to be form C, there can be names that the display device happen to show as the same to the user but for the program are different, that can result in security problems. In all other areas I have seen working with text/UCS, they want one normalisation and one form to avoid more than one representation for the same thing. This because of security matters and to make things much simpler to handle. >> Even if I switched to UTF-8 as my local character set it will fail, if >> the UTF-8 encoded text is not normalised form C. No other form >> is acceptible to use due to things like invalid semantics, to >> much data space and complex and CPU consuming handling of that format. > >User-level code will have to be able to cope with unnormalized Unicode >text [by normalizing as necessary], with or w/o NFSv4. Not at all. Most user and os kernel code need only handle UTF-8 in form C. At least in the Unix/Linux world. That is the standard format used there. > >> You cannot expect systems to switch to unnormalised UTF-8 in their >> file system to help NFSv4. It will break most applications. > >The C runtime environment will have to do as much normalization as is >necessary under the hood, yes. Not at all. The C runtime will read the file names through the kernal system calls and expect/deliver UTF-8 form C (or legacy encoding). Unnormalised or form D will break the applications. There is no reason to allow unnormalised or form D text as that will just require more memory, complexer code and more CPU power. If we get NFSv4 code into the kernel that do not return the file names as UCS form C (or legacy encoding), we will definitely get problems. >Pages 572 and 573 of the same book mentioned above make it very clear to >me that composites added after Unicode 3.0 are disalloed in text >normalized to form C. The book references Unicode Annex #15. > Yes, that is to make in unnecessary for form C to have new precomposed characters being added later. But as each revision comes along, new characters will be included in form C too. Regards, Dan From owner-nfsv4-wg@sunroof.eng.sun.com Wed Feb 5 00:37:29 2003 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16536 for ; Wed, 5 Feb 2003 00:37:28 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28140; Tue, 4 Feb 2003 21:33:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h155WeVL026363; Tue, 4 Feb 2003 21:32:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h155WTQb021507 for ; Tue, 4 Feb 2003 21:32:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h155WTmP021506 for nfsv4-wg-dist; Tue, 4 Feb 2003 21:32:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.Central.Sun.COM [129.147.62.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h155WRQb021499 for ; Tue, 4 Feb 2003 21:32:27 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h155WY7L027563; Tue, 4 Feb 2003 22:32:34 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h155UqQx022623; Tue, 4 Feb 2003 21:30:52 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h155Up4n022622; Tue, 4 Feb 2003 23:30:51 -0600 (CST) Date: Tue, 4 Feb 2003 23:30:51 -0600 From: Nicolas Williams To: Dan Oscarsson Cc: nfsv4-wg@sunroof.eng.sun.com Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] Message-ID: <20030204233051.A18728@binky.central.sun.com> References: <200302031627.h13GR7n13942@malmo.trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200302031627.h13GR7n13942@malmo.trab.se>; from Dan.Oscarsson@kiconsulting.se on Mon, Feb 03, 2003 at 05:29:58PM +0100 Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 3506 Lines: 78 On Mon, Feb 03, 2003 at 05:29:58PM +0100, Dan Oscarsson wrote: > >happy (my security instincts say that nonetheless the server should > >enforce a normalization form, but I can't yet find a convincing security > >argument). > > Well, as many programs will not check for unnormalised or different > normalisations and instead expect the code to be form C, there can be > names that the display device happen to show as the same to the user > but for the program are different, that can result in security > problems. I was thinking along those lines, and along the lines of covert channels (could a filename which cannot be referenced by most clients be a covert channel?) But then, this problem exists today - most users may not even notice a file named " ", say. So I don't think a new problem is introduced by not requiring that the server enforce a normalization form. > In all other areas I have seen working with text/UCS, they want one > normalisation and one form to avoid more than one representation > for the same thing. This because of security matters and to make things > much simpler to handle. Yes, but here we're not talking about naming security entities, as in Kerberos, or domain labels, in DNS/IDN. So the security implications of not enforcing a normalization form are different from those in Kerberos, DNS, PKI, or what have you. > > >> Even if I switched to UTF-8 as my local character set it will fail, if > >> the UTF-8 encoded text is not normalised form C. No other form > >> is acceptible to use due to things like invalid semantics, to > >> much data space and complex and CPU consuming handling of that format. > > > >User-level code will have to be able to cope with unnormalized Unicode > >text [by normalizing as necessary], with or w/o NFSv4. > > Not at all. Most user and os kernel code need only handle UTF-8 in form C. > At least in the Unix/Linux world. That is the standard format used there. What I was getting at is that if the server does not enforce a normalization form for filenames then the clients had better use one normalization form to avoid interop problems, and if the client does the normalization then that task can be moved to user-level, as in libc. > > > >> You cannot expect systems to switch to unnormalised UTF-8 in their > >> file system to help NFSv4. It will break most applications. > > > >The C runtime environment will have to do as much normalization as is > >necessary under the hood, yes. > > Not at all. The C runtime will read the file names through the kernal > system calls and expect/deliver UTF-8 form C (or legacy encoding). > Unnormalised or form D will break the applications. I'm talking about where codeset conversions and/or normalization of filename arguments to system calls should take place - in the library stubs? or in the kernel? This is an implementation detail, of course. > >Pages 572 and 573 of the same book mentioned above make it very clear to > >me that composites added after Unicode 3.0 are disalloed in text > >normalized to form C. The book references Unicode Annex #15. > > > > Yes, that is to make in unnecessary for form C to have new precomposed > characters being added later. But as each revision comes along, new > characters will be included in form C too. New pre-composed characters can and have been added to the Unicode repertorire, but not to normalization form C; you could say that over time normalization form C will asymptotically approach form D :) Cheers, Nico -- From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 11:47:49 2003 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25416 for ; Thu, 6 Feb 2003 11:47:49 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09181; Thu, 6 Feb 2003 09:46:48 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16GjvVL020769; Thu, 6 Feb 2003 08:45:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16GjjQb002527 for ; Thu, 6 Feb 2003 08:45:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16GjjCu002526 for nfsv4-wg-dist; Thu, 6 Feb 2003 08:45:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16GjhQb002519 for ; Thu, 6 Feb 2003 08:45:43 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16GjqVL020733 for ; Thu, 6 Feb 2003 08:45:52 -0800 (PST) Received: from malmo.trab.se (malmo.kicore.net [131.115.48.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23843; Thu, 6 Feb 2003 08:45:42 -0800 (PST) Received: from terra (terra.malmo.kicore.net [217.212.0.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id h16Gjen06372; Thu, 6 Feb 2003 17:45:40 +0100 (MET) Message-Id: <200302061645.h16Gjen06372@malmo.trab.se> Date: Thu, 6 Feb 2003 17:48:32 +0100 (CET) From: Dan Oscarsson Reply-To: Dan Oscarsson Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] To: Nicolas.Williams@sun.com Cc: nfsv4-wg@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ErEpHC7LlzvqwZB/cwoV6A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 sun4u sparc Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 1307 Lines: 26 >What I was getting at is that if the server does not enforce a >normalization form for filenames then the clients had better use one >normalization form to avoid interop problems, and if the client does the >normalization then that task can be moved to user-level, as in libc. > Yes, and because of that I think the protocol must mandate normalisation form C. Then the server (kernel) code kan assume the format to be that and do not need to do any normalisation. If a client sends text in another form and thereby violates the protocol strange things may happen and bad answers. That is ok, that should happen if you do not follow the protocol. The whole meaning of defining a protocol is to agree on what "language" to speak and the meaning of the "words". If the protocol says UCS form C encoded using UTF-8 and somebody transmitts UCS-2 you violates the protocol. If we define the normalisation form to be "undefined", we get a protocol where the "words" are loosly defined. I see no reason to allow more than one form of a "word". Why complicate the world? By selecting the most favoured normalisation form many systems can directely send text over the protocol without change. Both the Unix community and the World Wide Web have selected form C to be used. I am sure there are many more. Dan From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 11:57:23 2003 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25681 for ; Thu, 6 Feb 2003 11:57:22 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00513; Thu, 6 Feb 2003 08:53:46 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16GqwVK004634; Thu, 6 Feb 2003 08:52:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16GqkQb002555 for ; Thu, 6 Feb 2003 08:52:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16Gqjdt002554 for nfsv4-wg-dist; Thu, 6 Feb 2003 08:52:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.Central.Sun.COM [129.147.62.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16GqhQb002547 for ; Thu, 6 Feb 2003 08:52:44 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16Gqq7L002545; Thu, 6 Feb 2003 09:52:52 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h16Gp9Qx023799; Thu, 6 Feb 2003 08:51:09 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h16Gp9wA023798; Thu, 6 Feb 2003 10:51:09 -0600 (CST) Date: Thu, 6 Feb 2003 10:51:09 -0600 From: Nicolas Williams To: Dan Oscarsson Cc: nfsv4-wg@sunroof.eng.sun.com Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] Message-ID: <20030206105109.Y18728@binky.central.sun.com> References: <200302061645.h16Gjen06372@malmo.trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200302061645.h16Gjen06372@malmo.trab.se>; from Dan.Oscarsson@kiconsulting.se on Thu, Feb 06, 2003 at 05:48:32PM +0100 Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 1926 Lines: 41 On Thu, Feb 06, 2003 at 05:48:32PM +0100, Dan Oscarsson wrote: > >What I was getting at is that if the server does not enforce a > >normalization form for filenames then the clients had better use one > >normalization form to avoid interop problems, and if the client does the > >normalization then that task can be moved to user-level, as in libc. > > > > Yes, and because of that I think the protocol must mandate > normalisation form C. Then the server (kernel) code kan assume the > format to be that and do not need to do any normalisation. If a client > sends text in another form and thereby violates the protocol strange > things may happen and bad answers. That is ok, that should happen if > you do not follow the protocol. The whole meaning of defining a protocol > is to agree on what "language" to speak and the meaning of the "words". > If the protocol says UCS form C encoded using UTF-8 and somebody > transmitts UCS-2 you violates the protocol. I agree, with the caveat that the server MUST check that the filenames contain only valid UTF-8 encodings (this is fairly simple, though, unfortunately, not very efficient, but much, much more efficient than enforcing a normalization). I think we may end up drafting something to this end as a separate document. > If we define the normalisation form to be "undefined", we get a protocol > where the "words" are loosly defined. I see no reason to allow more than > one form of a "word". Why complicate the world? By selecting the most > favoured normalisation form many systems can directely send text over > the protocol without change. Both the Unix community and the World Wide Web > have selected form C to be used. I am sure there are many more. If normalization has to be done on the server, then I favor form D, if it can be pushed to the client, then I favor whatever form is most common amongst clients (which is likely to be C). Cheers, Nico -- From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 12:08:47 2003 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26157 for ; Thu, 6 Feb 2003 12:08:46 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14816; Thu, 6 Feb 2003 10:09:38 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16H8xVK009544; Thu, 6 Feb 2003 09:08:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16H8lQb002597 for ; Thu, 6 Feb 2003 09:08:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16H8lAf002596 for nfsv4-wg-dist; Thu, 6 Feb 2003 09:08:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16H8iQb002588 for ; Thu, 6 Feb 2003 09:08:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16H8rVK009487 for ; Thu, 6 Feb 2003 09:08:53 -0800 (PST) Received: from citi.umich.edu (citi.umich.edu [141.211.92.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20767 for ; Thu, 6 Feb 2003 10:08:46 -0700 (MST) Received: from citi.umich.edu (dumaguete.citi.umich.edu [141.211.92.168]) by citi.umich.edu (Postfix) with ESMTP id 1BCCF207F7 for ; Thu, 6 Feb 2003 12:08:37 -0500 (EST) Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] To: nfsv4-wg@sunroof.eng.sun.com From: Jim Rees In-Reply-To: Nicolas Williams, Thu, 06 Feb 2003 10:51:09 CST Date: Thu, 06 Feb 2003 12:08:37 -0500 Message-Id: <20030206170837.1BCCF207F7@citi.umich.edu> Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 344 Lines: 6 I would be opposed to requiring the server to check file names for valid UTF-8 form C. Is this really necessary? Unix (and nfs) file systems have never checked file names for validity in the past. This can result in some suprising behavior if the application (or client) misbehave, but I would vote for sticking with tradition on this one. From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 12:20:31 2003 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26653 for ; Thu, 6 Feb 2003 12:20:30 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23870; Thu, 6 Feb 2003 10:21:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HLPVL002485; Thu, 6 Feb 2003 09:21:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HLDQb002627 for ; Thu, 6 Feb 2003 09:21:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16HLDdb002626 for nfsv4-wg-dist; Thu, 6 Feb 2003 09:21:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.Central.Sun.COM [129.147.62.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HLBQb002619 for ; Thu, 6 Feb 2003 09:21:11 -0800 (PST) Received: from Sun.COM (jetsun.Central.Sun.COM [129.153.128.60]) by centralmail1brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HLK7L014283 for ; Thu, 6 Feb 2003 10:21:21 -0700 (MST) Message-ID: <3E429990.2050705@Sun.COM> Date: Thu, 06 Feb 2003 11:21:20 -0600 From: David Robinson Reply-To: David.Robinson@sun.com Organization: Sun Microsystems, Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] References: <200302061645.h16Gjen06372@malmo.trab.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3536 Lines: 70 Dan Oscarsson wrote: >>What I was getting at is that if the server does not enforce a >>normalization form for filenames then the clients had better use one >>normalization form to avoid interop problems, and if the client does the >>normalization then that task can be moved to user-level, as in libc. >> > > > Yes, and because of that I think the protocol must mandate > normalisation form C. Then the server (kernel) code kan assume the > format to be that and do not need to do any normalisation. If a client > sends text in another form and thereby violates the protocol strange > things may happen and bad answers. That is ok, that should happen if > you do not follow the protocol. The whole meaning of defining a protocol > is to agree on what "language" to speak and the meaning of the "words". > If the protocol says UCS form C encoded using UTF-8 and somebody > transmitts UCS-2 you violates the protocol. > If we define the normalisation form to be "undefined", we get a protocol > where the "words" are loosly defined. I see no reason to allow more than > one form of a "word". Why complicate the world? By selecting the most > favoured normalisation form many systems can directely send text over > the protocol without change. Both the Unix community and the World Wide Web > have selected form C to be used. I am sure there are many more. I am far from an expert on normalization, but in following this thread it seem to boil down to the question of "who makes it right" and what "right" is. For the latter, I am going to defer to the normalization experts to determine what is the best "form". Traditionally NFS has had a philosophy of dumb servers and smart clients which has allowed development of high performance low impact servers. The client was the party that was responsible for mapping its semantics on to the protocol definition. Based on this and my understanding of Unicode, at most the server should be limited to validating that the utf8 string it receives is actually a valid encoding, the server should not perform the complex process of normalization. If we follow this approach, two clients that use different encoding schemes may send different utf8 strings to access the same file, one or both may fail depending on the form the server stored the name in. Again for simplicity the server is just doing a bitwise comparision. Some files may be inaccessible by certain clients, but as Nico says above, we already have this today and it doesn't seem to be a problem. To help this problem we can either mandate a normalization form on the wire, "MUST use form XYZ" or we can recommend that clients use a common normalization form, "SHOULD use form XYZ". I would tend to favor the latter as it allows clients in a homogenous environment to not pay the price of normalizing to an unfavorable encoding. It is also useful to note that if a filename uses an encoding that is not the preferred encoding, the client can still access it by simply performing a READDIR and returning the bits acquired in a subsequent LOOKUP. What is presented to the application need not be what the server returns, as long as the client performs the mapping function. So the interesting options are: 1) Server performs normalization 2) Protocol specifies wire standard normalization 3) Client uses recommended common normalization Given where we are in the IETF process, I suggest #3 and the WG publish the recommended normalization form. Over time, (in a minor version?) we could migrate to option #2. -David From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 12:30:05 2003 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27047 for ; Thu, 6 Feb 2003 12:30:04 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00730; Thu, 6 Feb 2003 10:31:10 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HUUVK016710; Thu, 6 Feb 2003 09:30:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HUIQb002652 for ; Thu, 6 Feb 2003 09:30:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16HUIHk002651 for nfsv4-wg-dist; Thu, 6 Feb 2003 09:30:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HUGQb002644 for ; Thu, 6 Feb 2003 09:30:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HUPVL005863 for ; Thu, 6 Feb 2003 09:30:25 -0800 (PST) Received: from mx01.netapp.com (mx01.netapp.com [198.95.226.53]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00052 for ; Thu, 6 Feb 2003 10:30:19 -0700 (MST) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01.netapp.com (8.12.6/8.12.6/NTAP-1.4) with ESMTP id h16HUJYW015560; Thu, 6 Feb 2003 09:30:19 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by frejya.corp.netapp.com (8.12.6/8.12.6/NTAP-1.4) with ESMTP id h16HUJv6016944; Thu, 6 Feb 2003 09:30:19 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 6 Feb 2003 09:30:08 -0800 Message-ID: Thread-Topic: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] Thread-Index: AcLOAo/O+lG64KBfRdemcAQWW4kroQAAGnpg From: "Noveck, Dave" To: "Jim Rees" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h16HUGQb002645 Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Status: RO Content-Length: 1971 Lines: 44 I want to separate the two issues. Checking UTF-8 and checking form C. It's my impression that the spec already requires that you check stuff that supposed to be utf-8 and reject it if it isn't valid utf-8. I can't quote a specific statement to that effect but when it says that that's what's valid, my conclusion is that anything else is invalid. In fact, on my bug list (way down, to be sure) is a problem that Peter Astrand's test suite complains that I don't reject a *tag* that doesn't consist of valid UTF-8. As to checking form C, it really doesn't make much difference to me whether the spec requires the server to check it. Saying that the client has to produce correct form C, but that the server doesn't have to check it, with the client getting "weird" results if he uses the wrong form, is not something that I would be prepared to live with. I would wind up checking the normalization rather than having to wonder, in any internationalization situation in which something wierd happened, whether a client with bad normalization was involved. I'm assuming that checking for valid normalization form C is simpler than actually doing the normalization. I'm hoping that for most actual strings processed the execution time will be roughly comparable to just checking UTF-8, even though there will obviously be examples that are considerably more expensive to process. -----Original Message----- From: Jim Rees [mailto:rees@umich.edu] Sent: Thursday, February 06, 2003 12:09 PM To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] I would be opposed to requiring the server to check file names for valid UTF-8 form C. Is this really necessary? Unix (and nfs) file systems have never checked file names for validity in the past. This can result in some suprising behavior if the application (or client) misbehave, but I would vote for sticking with tradition on this one. From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 12:35:12 2003 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27262 for ; Thu, 6 Feb 2003 12:35:12 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14123; Thu, 6 Feb 2003 10:36:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HZlVL007872; Thu, 6 Feb 2003 09:35:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HZZQb002683 for ; Thu, 6 Feb 2003 09:35:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16HZZSr002682 for nfsv4-wg-dist; Thu, 6 Feb 2003 09:35:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HZXQb002675 for ; Thu, 6 Feb 2003 09:35:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HZgVL007804 for ; Thu, 6 Feb 2003 09:35:42 -0800 (PST) Received: from malmo.trab.se (malmo.kicore.net [131.115.48.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21891 for ; Thu, 6 Feb 2003 10:35:36 -0700 (MST) Received: from terra (terra.malmo.kicore.net [217.212.0.22]) by malmo.trab.se (8.10.1/TRAB-primary-2) with SMTP id h16HZYn09779 for ; Thu, 6 Feb 2003 18:35:34 +0100 (MET) Message-Id: <200302061735.h16HZYn09779@malmo.trab.se> Date: Thu, 6 Feb 2003 18:38:27 +0100 (CET) From: Dan Oscarsson Reply-To: Dan Oscarsson Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] To: nfsv4-wg@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yi2WDNgKJN1muWC06/5uag== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5 SunOS 5.9 sun4u sparc Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 1125 Lines: 24 David Robinson wrote: >If we follow this approach, two clients that use different encoding >schemes may send different utf8 strings to access the same file, one >or both may fail depending on the form the server stored the name in. >Again for simplicity the server is just doing a bitwise comparision. >Some files may be inaccessible by certain clients, but as Nico says >above, we already have this today and it doesn't seem to be a problem. Yes, we have that problem today. And it is a VERY BIG problem. Not for you who use ASCII, but for us who use letters outside ASCII. NFS as it is today is unusable the moment you need more than ASCII and use systems with different encodings. I have had this problem for many years. The only working file sharing code I have had is the open source file sharing code I have fixed to use the same format on the wire. I hoped that NFSv4 finally should allow me to mount file systems between systems of different type, and get a working file sharing. If the protocol do not mandate format to use, I am sure I will have the same problems with NFSv4 as with previous version. Dan From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 12:43:08 2003 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27534 for ; Thu, 6 Feb 2003 12:43:07 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08185; Thu, 6 Feb 2003 09:39:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HcvVK019553; Thu, 6 Feb 2003 09:38:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HciQb002695 for ; Thu, 6 Feb 2003 09:38:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16Hcibv002694 for nfsv4-wg-dist; Thu, 6 Feb 2003 09:38:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.Central.Sun.COM [129.147.62.14]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HcgQb002686 for ; Thu, 6 Feb 2003 09:38:42 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16Hcpln017731; Thu, 6 Feb 2003 10:38:51 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h16Hb8Qx023814; Thu, 6 Feb 2003 09:37:08 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h16Hb7TV023813; Thu, 6 Feb 2003 11:37:07 -0600 (CST) Date: Thu, 6 Feb 2003 11:37:07 -0600 From: Nicolas Williams To: "Noveck, Dave" Cc: Jim Rees , nfsv4-wg@sunroof.eng.sun.com Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] Message-ID: <20030206113707.Z18728@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Dave.Noveck@netapp.com on Thu, Feb 06, 2003 at 09:30:08AM -0800 Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 1948 Lines: 46 On Thu, Feb 06, 2003 at 09:30:08AM -0800, Noveck, Dave wrote: > I want to separate the two issues. Checking UTF-8 and > checking form C. These two are, in fact, distinct. > It's my impression that the spec already requires that > you check stuff that supposed to be utf-8 and reject it > if it isn't valid utf-8. I can't quote a specific statement > to that effect but when it says that that's what's valid, my > conclusion is that anything else is invalid. In fact, > on my bug list (way down, to be sure) is a problem that > Peter Astrand's test suite complains that I don't reject > a *tag* that doesn't consist of valid UTF-8. The spec speaks of UTF-8 throughout - I don't see how it could be construed as correct behaviour to allow non-UTF-8 encodings or invalid UTF-8 encodings (e.g., overlong sequences). > As to checking form C, it really doesn't make much difference > to me whether the spec requires the server to check it. Saying > that the client has to produce correct form C, but that the > server doesn't have to check it, with the client getting "weird" > results if he uses the wrong form, is not something that I > would be prepared to live with. I would wind up checking > the normalization rather than having to wonder, in any > internationalization situation in which something wierd > happened, whether a client with bad normalization was involved. It would be useful to have benchamrks of Unicode normalization. > I'm assuming that checking for valid normalization form C > is simpler than actually doing the normalization. I'm hoping > that for most actual strings processed the execution time > will be roughly comparable to just checking UTF-8, even though > there will obviously be examples that are considerably more > expensive to process. Your assumption is correct. I don't know about the perf aspect, but users of mostly-ASCII filenames would likely not notice any impact. Cheers, Nico -- From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 12:46:55 2003 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27615 for ; Thu, 6 Feb 2003 12:46:54 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11483; Thu, 6 Feb 2003 09:43:12 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HgNVL010230; Thu, 6 Feb 2003 09:42:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HgAQb002771 for ; Thu, 6 Feb 2003 09:42:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16HgAm8002770 for nfsv4-wg-dist; Thu, 6 Feb 2003 09:42:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.Central.Sun.COM [129.147.62.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16Hg8Qb002763 for ; Thu, 6 Feb 2003 09:42:09 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HgH7L023132; Thu, 6 Feb 2003 10:42:17 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h16HeYQx023821; Thu, 6 Feb 2003 09:40:34 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h16HeYSm023820; Thu, 6 Feb 2003 11:40:34 -0600 (CST) Date: Thu, 6 Feb 2003 11:40:34 -0600 From: Nicolas Williams To: Dan Oscarsson Cc: nfsv4-wg@sunroof.eng.sun.com Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] Message-ID: <20030206114034.A18728@binky.central.sun.com> References: <200302061735.h16HZYn09779@malmo.trab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200302061735.h16HZYn09779@malmo.trab.se>; from Dan.Oscarsson@kiconsulting.se on Thu, Feb 06, 2003 at 06:38:27PM +0100 Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 1514 Lines: 34 On Thu, Feb 06, 2003 at 06:38:27PM +0100, Dan Oscarsson wrote: > David Robinson wrote: > > >If we follow this approach, two clients that use different encoding > >schemes may send different utf8 strings to access the same file, one > >or both may fail depending on the form the server stored the name in. > >Again for simplicity the server is just doing a bitwise comparision. > >Some files may be inaccessible by certain clients, but as Nico says > >above, we already have this today and it doesn't seem to be a problem. > > Yes, we have that problem today. And it is a VERY BIG problem. > Not for you who use ASCII, but for us who use letters outside ASCII. > > NFS as it is today is unusable the moment you need more than ASCII > and use systems with different encodings. I have had this problem > for many years. The only working file sharing code I have had is > the open source file sharing code I have fixed to use the same > format on the wire. I hoped that NFSv4 finally should allow me to mount > file systems between systems of different type, and get a working > file sharing. If the protocol do not mandate format to use, I am sure > I will have the same problems with NFSv4 as with previous version. As NFSv4 stands the client can make it right, so the protocol is OK. It'll be less painful if we at least recommend a normalization form to use for filenames when they are created. Let me repeat, NFSv4 is not broken here wrt normalization forms - at worst it is sub-optimal. Cheers, Nico -- From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 12:49:01 2003 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27713 for ; Thu, 6 Feb 2003 12:49:00 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13700; Thu, 6 Feb 2003 09:46:03 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HjEVK021943; Thu, 6 Feb 2003 09:45:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16Hj2Qb002783 for ; Thu, 6 Feb 2003 09:45:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16Hj2Kg002782 for nfsv4-wg-dist; Thu, 6 Feb 2003 09:45:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16Hj0Qb002775 for ; Thu, 6 Feb 2003 09:45:00 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16Hj9VL010988 for ; Thu, 6 Feb 2003 09:45:09 -0800 (PST) Received: from mx01.netapp.com (mx01.netapp.com [198.95.226.53]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11469; Thu, 6 Feb 2003 10:45:04 -0700 (MST) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01.netapp.com (8.12.6/8.12.6/NTAP-1.4) with ESMTP id h16Hj3YW016739; Thu, 6 Feb 2003 09:45:03 -0800 (PST) Received: from ussvlexc01.corp.netapp.com (ussvlexc01.corp.netapp.com [10.10.22.169]) by frejya.corp.netapp.com (8.12.6/8.12.6/NTAP-1.4) with ESMTP id h16Hj1v6020295; Thu, 6 Feb 2003 09:45:03 -0800 (PST) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Feb 2003 09:45:01 -0800 Message-ID: From: "Noveck, Dave" To: "'Nicolas Williams'" Cc: Jim Rees , nfsv4-wg@sunroof.eng.sun.com Subject: RE: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis- 05 draft] Date: Thu, 6 Feb 2003 09:44:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 496 Lines: 12 > > In fact, > > on my bug list (way down, to be sure) is a problem that > > Peter Astrand's test suite complains that I don't reject > > a *tag* that doesn't consist of valid UTF-8. > > The spec speaks of UTF-8 throughout - I don't see how it could be > construed as correct behaviour to allow non-UTF-8 encodings or invalid > UTF-8 encodings (e.g., overlong sequences). Damn! Another guy bothering me about fixing that stinking problem with non-UTF-8 tags. It never lets up, does it? :-) From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 12:58:17 2003 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28194 for ; Thu, 6 Feb 2003 12:58:16 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21837; Thu, 6 Feb 2003 10:59:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HweVK026364; Thu, 6 Feb 2003 09:58:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HwRQb002971 for ; Thu, 6 Feb 2003 09:58:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16HwRAM002970 for nfsv4-wg-dist; Thu, 6 Feb 2003 09:58:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.Central.Sun.COM [129.147.62.14]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16HwPQb002963 for ; Thu, 6 Feb 2003 09:58:26 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16HwXln025583; Thu, 6 Feb 2003 10:58:33 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h16HuoQx023833; Thu, 6 Feb 2003 09:56:50 -0800 (PST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h16Huoxr023832; Thu, 6 Feb 2003 11:56:50 -0600 (CST) Date: Thu, 6 Feb 2003 11:56:50 -0600 From: Nicolas Williams To: "Noveck, Dave" Cc: Jim Rees , nfsv4-wg@sunroof.eng.sun.com Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft] Message-ID: <20030206115650.B18728@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Dave.Noveck@netapp.com on Thu, Feb 06, 2003 at 09:30:08AM -0800 Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 1553 Lines: 39 Perhaps there is a neat compromise: - RECOMMEND a normalization form to clients that they are responsible for using and converting to/from - RECOMMEND that the server enforce a normalization form ONLY for new filenames (creates/renames/links) This way the server can guarantee that the filesystem will contain only filenames with the proper normalization without having to perform normalization very often (only when files are created/renamed/linked with non-ASCII names), thus limiting the perf impact of doing normalization on the server, and the client is responsible for normalizing before doing LOOKUPs. (Multi-protocol servers may have to deal with normalization more generally, but that's a function of the protocols in question). Section 11.4 of the draft already specifies an error to make this possible. All that'd be needed is an I-D that hands down the two recommendations. Cheers, Nico On Thu, Feb 06, 2003 at 09:30:08AM -0800, Noveck, Dave wrote: ... > As to checking form C, it really doesn't make much difference > to me whether the spec requires the server to check it. Saying > that the client has to produce correct form C, but that the > server doesn't have to check it, with the client getting "weird" > results if he uses the wrong form, is not something that I > would be prepared to live with. I would wind up checking > the normalization rather than having to wonder, in any > internationalization situation in which something wierd > happened, whether a client with bad normalization was involved. ... From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 13:44:50 2003 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29901 for ; Thu, 6 Feb 2003 13:44:49 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10502; Thu, 6 Feb 2003 10:41:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16IeoVL000028; Thu, 6 Feb 2003 10:40:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16IecQb003057 for ; Thu, 6 Feb 2003 10:40:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16IecOn003056 for nfsv4-wg-dist; Thu, 6 Feb 2003 10:40:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16IeaQb003049 for ; Thu, 6 Feb 2003 10:40:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16IejVL029989 for ; Thu, 6 Feb 2003 10:40:45 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26484 for ; Thu, 6 Feb 2003 10:40:40 -0800 (PST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e35.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h16IedJE040344 for ; Thu, 6 Feb 2003 13:40:39 -0500 Received: from d03nm113.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h16IecxM063606 for ; Thu, 6 Feb 2003 11:40:39 -0700 Subject: Minor Versions To: nfsv4-wg@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Stevan Steve Allen Date: Thu, 6 Feb 2003 10:40:01 -0800 X-MIMETrack: Serialize by Router on D03NM113/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/06/2003 11:40:39 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 530 Lines: 15 Attributes are currently available for minor versioning. Is there a need to add open rflags to minor versioning for cases where file attributes may not be the proper location or sequence if events? A coding guideline used in my circle - if a process can not complete, it is cleaner to prevent the process from starting. Mid process termination may lead to unknown results (debug) & wasted system resources. This guideline may use early indicators such as open rflags or file attributes to determine ability to complete. From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 13:53:11 2003 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00138 for ; Thu, 6 Feb 2003 13:53:10 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04484; Thu, 6 Feb 2003 11:54:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16IrAVL004884; Thu, 6 Feb 2003 10:53:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16IqwQb003186 for ; Thu, 6 Feb 2003 10:52:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16Iqwco003185 for nfsv4-wg-dist; Thu, 6 Feb 2003 10:52:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16IquQb003178 for ; Thu, 6 Feb 2003 10:52:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16Ir6VK015542 for ; Thu, 6 Feb 2003 10:53:06 -0800 (PST) Received: from mx01.netapp.com (mx01.netapp.com [198.95.226.53]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07971 for ; Thu, 6 Feb 2003 11:53:00 -0700 (MST) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01.netapp.com (8.12.6/8.12.6/NTAP-1.4) with ESMTP id h16Ir0YW021813; Thu, 6 Feb 2003 10:53:00 -0800 (PST) Received: from ussvlexc01.corp.netapp.com (ussvlexc01.corp.netapp.com [10.10.22.169]) by frejya.corp.netapp.com (8.12.6/8.12.6/NTAP-1.4) with ESMTP id h16Iqxv6006652; Thu, 6 Feb 2003 10:52:59 -0800 (PST) Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Feb 2003 10:52:59 -0800 Message-ID: From: "Noveck, Dave" To: "'Stevan Steve Allen'" , nfsv4-wg@sunroof.eng.sun.com Subject: RE: Minor Versions Date: Thu, 6 Feb 2003 10:52:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 1164 Lines: 34 > Attributes are currently available for minor versioning. Attributes can be added in a minor version. Attributes cannot be officially deleted in a minor version, but they can be made mandatory to not implement which serves the practical purpose pretty well. > Is there a need > to add open rflags to minor versioning for cases where file attributes may > not be the proper location or sequence if events? You can add new flags to fields like the open rflags in a minor version. I'm not clear what kind of situation you think needs to be represented in a new rflags bit. > A coding guideline used in my circle - if a process can not complete, it is > cleaner to prevent the process from starting. That's great if you can know that. > Mid process termination may > lead to unknown results (debug) & wasted system resources. Sure, but in lots of cases you can't predict. > This guideline > may use early indicators such as open rflags or file attributes to > determine ability to complete. You might but wouldn't that be application-specific? What new attributes or rflags could you propose that would shed light on this issue, in a general way? From owner-nfsv4-wg@sunroof.eng.sun.com Thu Feb 6 14:28:43 2003 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01151 for ; Thu, 6 Feb 2003 14:28:42 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13611; Thu, 6 Feb 2003 12:29:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16JTIVK028021; Thu, 6 Feb 2003 11:29:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16JT6Qb003846 for ; Thu, 6 Feb 2003 11:29:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h16JT64K003845 for nfsv4-wg-dist; Thu, 6 Feb 2003 11:29:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h16JT4Qb003838 for ; Thu, 6 Feb 2003 11:29:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h16JTDVK027960 for ; Thu, 6 Feb 2003 11:29:13 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04397 for ; Thu, 6 Feb 2003 12:28:56 -0700 (MST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h16JSril060076 for ; Thu, 6 Feb 2003 14:28:53 -0500 Received: from d03nm113.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h16JSpxM214784 for ; Thu, 6 Feb 2003 12:28:52 -0700 Subject: RE: Minor Versions To: nfsv4-wg@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Stevan Steve Allen Date: Thu, 6 Feb 2003 11:28:10 -0800 X-MIMETrack: Serialize by Router on D03NM113/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 02/06/2003 12:28:51 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 555 Lines: 19 An existing example is rflag OPEN4_RESULT_LOCKTYPE_POSIX. A client may use this to prevent midstream failures (e.g. appl locking successful during delegation, fails after recall because the server may not support partial subrange locks). Is there a reason this posix indicator is in rflags opposed to an attribute? > You can add new flags to fields like the open rflags in > a minor version. My mistake, I did not find rflags in chpt 10 Minor Versioning. I read only attributes & compound are available for minor versions. From owner-nfsv4-wg@sunroof.eng.sun.com Fri Feb 7 16:21:18 2003 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21769 for ; Fri, 7 Feb 2003 16:21:18 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10113; Fri, 7 Feb 2003 14:22:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17LLWVL015596; Fri, 7 Feb 2003 13:21:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17LLIQb012438 for ; Fri, 7 Feb 2003 13:21:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17LLI6T012437 for nfsv4-wg-dist; Fri, 7 Feb 2003 13:21:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17LLGQb012428 for ; Fri, 7 Feb 2003 13:21:16 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17LLPVK010105 for ; Fri, 7 Feb 2003 13:21:25 -0800 (PST) Received: from mxic1.corp.emc.com ([128.222.32.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01742 for ; Fri, 7 Feb 2003 13:21:19 -0800 (PST) From: Dai_Peng@emc.com Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id <1KDYNM2V>; Fri, 7 Feb 2003 16:21:19 -0500 Message-ID: <6335CBB2F69AD411AD3100D0B7BA38E30CF0BF65@CORPUSMX2> To: nfsv4-wg@sunroof.eng.sun.com Subject: LOOKUPP and NFS4ERR_WRONGSEC Date: Fri, 7 Feb 2003 16:20:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 592 Lines: 20 As far as I understand, NFS4ERR_WRONGSEC is returned to the client when a compound request crosses into an export with incompatible security requirements. For example, in the following scenario, putfh [/foo/bar]; lookup "baz" will cause the error to be returned. /foo <-- auth_unix | /foo/bar | /foo/bar/baz <-- krb5 Using the same example, it seems that going the opposite direction using LOOKUPP would have the same problem. However, the spec did not include NFS4ERR_WRONGSEC as a possible error code for LOOKUPP. Is this an oversight or did I miss something? Thanks Peng From owner-nfsv4-wg@sunroof.eng.sun.com Fri Feb 7 16:26:13 2003 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21872 for ; Fri, 7 Feb 2003 16:26:12 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22675; Fri, 7 Feb 2003 14:26:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17LQeVL017071; Fri, 7 Feb 2003 13:26:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17LQSQb012466 for ; Fri, 7 Feb 2003 13:26:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17LQSOL012465 for nfsv4-wg-dist; Fri, 7 Feb 2003 13:26:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.Central.Sun.COM [129.147.62.14]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17LQQQb012458 for ; Fri, 7 Feb 2003 13:26:26 -0800 (PST) Received: from dhcp-uaus08-128-228.Central.Sun.COM (dhcp-uaus08-128-228.Central.Sun.COM [129.153.128.228]) by centralmail2brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17LQYln009238 for ; Fri, 7 Feb 2003 14:26:35 -0700 (MST) Received: from dhcp-uaus08-128-228.Central.Sun.COM (localhost [127.0.0.1]) by dhcp-uaus08-128-228.Central.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h17LOFfM100541 for ; Fri, 7 Feb 2003 15:24:15 -0600 (CST) Received: (from shepler@localhost) by dhcp-uaus08-128-228.Central.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h17LOF9I100540 for nfsv4-wg@sunroof.eng.sun.com; Fri, 7 Feb 2003 15:24:15 -0600 (CST) Date: Fri, 7 Feb 2003 15:24:15 -0600 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: LOOKUPP and NFS4ERR_WRONGSEC Message-ID: <20030207212415.GK100365@dhcp-uaus08-128-228.central.sun.com> Reply-To: spencer.shepler@sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <6335CBB2F69AD411AD3100D0B7BA38E30CF0BF65@CORPUSMX2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6335CBB2F69AD411AD3100D0B7BA38E30CF0BF65@CORPUSMX2> User-Agent: Mutt/1.4i Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 1024 Lines: 29 On Fri, Dai_Peng@emc.com wrote: > As far as I understand, NFS4ERR_WRONGSEC is returned to the client > when a compound request crosses into an export with incompatible security > requirements. For example, in the following scenario, putfh [/foo/bar]; > lookup "baz" > will cause the error to be returned. > > /foo <-- auth_unix > | > /foo/bar > | > /foo/bar/baz <-- krb5 > > Using the same example, it seems that going the opposite direction using > LOOKUPP would have the same problem. However, the spec did not include > NFS4ERR_WRONGSEC as a possible error code for LOOKUPP. Is this an > oversight or did I miss something? Not an oversight. The assumption is that if a object in the server's namespace requires a particular security mechanism for access that all ancestors of that object will accept the same security mechanism. This allows a client to use a single security mechanism while traversing the namespace to that node. It also avoids the problem that you thought might exist. -- Spencer From owner-nfsv4-wg@sunroof.eng.sun.com Fri Feb 7 16:49:17 2003 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22483 for ; Fri, 7 Feb 2003 16:49:16 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18070; Fri, 7 Feb 2003 13:45:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17LixVK017415; Fri, 7 Feb 2003 13:44:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17LilQb012513 for ; Fri, 7 Feb 2003 13:44:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17LilDI012512 for nfsv4-wg-dist; Fri, 7 Feb 2003 13:44:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17LiiQb012505 for ; Fri, 7 Feb 2003 13:44:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17LirVL022440 for ; Fri, 7 Feb 2003 13:44:53 -0800 (PST) Received: from tor01x3.hcl.com (torpsi.hcl.com [199.71.120.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17801 for ; Fri, 7 Feb 2003 14:44:45 -0700 (MST) Received: from av0012 (av0012.hcl.com [10.1.42.241]) by tor01x3.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DC3AHD5B; Fri, 7 Feb 2003 16:44:41 -0500 Received: FROM mhoutside.hcl.com BY av0012 ; Fri Feb 07 16:45:07 2003 -0500 Received: from sergeylt (sergeylt.hcl.com [10.1.14.156]) by mhoutside.hcl.com (8.11.2/8.11.2) with ESMTP id h17LilV00838; Fri, 7 Feb 2003 16:44:47 -0500 (EST) From: "Sergey Klyushin" To: , Subject: Definitions of utf8str_* in draft-ietf-nfsv4-rfc3010bis-05 Date: Fri, 7 Feb 2003 16:44:41 -0500 Message-ID: <002801c2cef2$1eefe180$9c0e010a@hcl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030124151406.GA100497@shepler.eng.sun.com> Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1507 Lines: 47 Hello Finally I've decided to update my nfs4_prot.h file from version 1.119 to version 1.120 of nfs4_prot.x (http://www.nfsv4.org/nfs4_prot.x) and http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rfc3010bis-05.txt I was really surprised with definition of utf8str_cis, utf8str_cs and utf8str_mixed. draft-ietf-nfsv4-rfc3010bis-05.txt: Paragraph 2.1. Basic Data Types utf8string typedef opaque utf8string<>; UTF-8 encoding for strings utf8str_cis typedef opaque utf8str_cis<>; Case-insensitive UTF-8 string utf8str_cs typedef opaque utf8str_cs<>; Case-sensitive UTF-8 string utf8str_mixed typedef opaque utf8str_mixed<>; UTF-8 strings with a case sensitive prefix and a case insensitive suffix. But later in Paragraph 18. RPC definition file and in http://www.nfsv4.org/nfs4_prot.x: typedef opaque utf8string<>; typedef utf8string utf8str_cis<>; typedef utf8string utf8str_cs<>; typedef utf8string utf8str_mixed<>; I believe that definitions in Paragraph 18 and in http://www.nfsv4.org/nfs4_prot.x are wrong and MUST be typedef opaque utf8string<>; typedef opaque utf8str_cis<>; typedef opaque utf8str_cs<>; typedef opaque utf8str_mixed<>; (or I really missed something) I hope it's not "too late" to change draft-ietf-nfsv4-rfc3010bis-05.txt. Thanks, Sergey From owner-nfsv4-wg@sunroof.eng.sun.com Fri Feb 7 17:06:55 2003 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23016 for ; Fri, 7 Feb 2003 17:06:55 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17322; Fri, 7 Feb 2003 15:08:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17M79VK024509; Fri, 7 Feb 2003 14:07:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17M6vQb012553 for ; Fri, 7 Feb 2003 14:06:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17M6v0K012552 for nfsv4-wg-dist; Fri, 7 Feb 2003 14:06:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17M6tQb012545 for ; Fri, 7 Feb 2003 14:06:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17M74VL029334 for ; Fri, 7 Feb 2003 14:07:04 -0800 (PST) Received: from mx01.netapp.com (mx01.netapp.com [198.95.226.53]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16661; Fri, 7 Feb 2003 15:06:58 -0700 (MST) Received: from frejya.corp.netapp.com (frejya [10.10.20.91]) by mx01.netapp.com (8.12.6/8.12.6/NTAP-1.4) with ESMTP id h17M6vYW012650; Fri, 7 Feb 2003 14:06:57 -0800 (PST) Received: from tahoe.corp.netapp.com (tahoe.corp.netapp.com [10.10.22.112]) by frejya.corp.netapp.com (8.12.6/8.12.6/NTAP-1.4) with ESMTP id h17M6vv6000149; Fri, 7 Feb 2003 14:06:57 -0800 (PST) Received: from eisler.com (10.58.48.120 [10.58.48.120]) by tahoe.corp.netapp.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1JT75K0P; Fri, 7 Feb 2003 14:06:48 -0800 Message-ID: <3E442DF7.8080100@eisler.com> Date: Fri, 07 Feb 2003 14:06:47 -0800 From: Mike Eisler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Sergey Klyushin CC: spencer.shepler@sun.com, nfsv4-wg@sunroof.eng.sun.com Subject: Re: Definitions of utf8str_* in draft-ietf-nfsv4-rfc3010bis-05 References: <002801c2cef2$1eefe180$9c0e010a@hcl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1816 Lines: 63 Sergey, Yes the .x file is wrong. Dave Noveck noticed this a week or so ago, and beepy gave IESG a heads up. Either we will spin another i-d, or fix it when the RFC editor gives the authors the final draft to review. Thx. -mre Sergey Klyushin wrote: >Hello > >Finally I've decided to update my nfs4_prot.h file from version 1.119 to >version 1.120 of nfs4_prot.x (http://www.nfsv4.org/nfs4_prot.x) >and http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rfc3010bis-05.txt > >I was really surprised with definition of utf8str_cis, utf8str_cs and >utf8str_mixed. > >draft-ietf-nfsv4-rfc3010bis-05.txt: Paragraph 2.1. Basic Data Types > > utf8string typedef opaque utf8string<>; > UTF-8 encoding for strings > > utf8str_cis typedef opaque utf8str_cis<>; > Case-insensitive UTF-8 string > > utf8str_cs typedef opaque utf8str_cs<>; > Case-sensitive UTF-8 string > > utf8str_mixed typedef opaque utf8str_mixed<>; > UTF-8 strings with a case sensitive prefix and > a case insensitive suffix. > >But later in Paragraph 18. RPC definition file >and in http://www.nfsv4.org/nfs4_prot.x: > > typedef opaque utf8string<>; > typedef utf8string utf8str_cis<>; > typedef utf8string utf8str_cs<>; > typedef utf8string utf8str_mixed<>; > >I believe that definitions in Paragraph 18 and in >http://www.nfsv4.org/nfs4_prot.x are wrong and MUST be > typedef opaque utf8string<>; > typedef opaque utf8str_cis<>; > typedef opaque utf8str_cs<>; > typedef opaque utf8str_mixed<>; >(or I really missed something) > >I hope it's not "too late" to change draft-ietf-nfsv4-rfc3010bis-05.txt. > >Thanks, >Sergey > > From owner-nfsv4-wg@sunroof.eng.sun.com Fri Feb 7 17:10:05 2003 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23112 for ; Fri, 7 Feb 2003 17:10:04 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14218; Fri, 7 Feb 2003 14:05:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17M4fVL028701; Fri, 7 Feb 2003 14:04:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17M4UQb012539 for ; Fri, 7 Feb 2003 14:04:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17M4U2A012538 for nfsv4-wg-dist; Fri, 7 Feb 2003 14:04:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.Central.Sun.COM [129.147.62.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17M4RQb012531 for ; Fri, 7 Feb 2003 14:04:27 -0800 (PST) Received: from dhcp-uaus08-128-228.Central.Sun.COM (dhcp-uaus08-128-228.Central.Sun.COM [129.153.128.228]) by centralmail1brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17M4a7L013344 for ; Fri, 7 Feb 2003 15:04:36 -0700 (MST) Received: from dhcp-uaus08-128-228.Central.Sun.COM (localhost [127.0.0.1]) by dhcp-uaus08-128-228.Central.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h17M2GfM100597 for ; Fri, 7 Feb 2003 16:02:16 -0600 (CST) Received: (from shepler@localhost) by dhcp-uaus08-128-228.Central.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h17M2GKl100596 for nfsv4-wg@sunroof.eng.sun.com; Fri, 7 Feb 2003 16:02:16 -0600 (CST) Date: Fri, 7 Feb 2003 16:02:16 -0600 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Definitions of utf8str_* in draft-ietf-nfsv4-rfc3010bis-05 Message-ID: <20030207220216.GO100365@dhcp-uaus08-128-228.central.sun.com> Reply-To: spencer.shepler@sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <20030124151406.GA100497@shepler.eng.sun.com> <002801c2cef2$1eefe180$9c0e010a@hcl.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline In-Reply-To: <002801c2cef2$1eefe180$9c0e010a@hcl.com> User-Agent: Mutt/1.4i Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 37195 Lines: 1710 --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sergey, Thanks for pointing this out. Someone else recently raised this issue as well in private mail and I have actually made updates such that the I-D will be updated during the final comments period provided by the RFC editor. For those that are interested, I have attached the updated nfs4_prot.x. Sorry about the spam but I want to make sure everyone has a copy. Spencer On Fri, Sergey Klyushin wrote: > Hello > > Finally I've decided to update my nfs4_prot.h file from version 1.119 to > version 1.120 of nfs4_prot.x (http://www.nfsv4.org/nfs4_prot.x) > and http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rfc3010bis-05.txt > > I was really surprised with definition of utf8str_cis, utf8str_cs and > utf8str_mixed. > > draft-ietf-nfsv4-rfc3010bis-05.txt: Paragraph 2.1. Basic Data Types > > utf8string typedef opaque utf8string<>; > UTF-8 encoding for strings > > utf8str_cis typedef opaque utf8str_cis<>; > Case-insensitive UTF-8 string > > utf8str_cs typedef opaque utf8str_cs<>; > Case-sensitive UTF-8 string > > utf8str_mixed typedef opaque utf8str_mixed<>; > UTF-8 strings with a case sensitive prefix and > a case insensitive suffix. > > But later in Paragraph 18. RPC definition file > and in http://www.nfsv4.org/nfs4_prot.x: > > typedef opaque utf8string<>; > typedef utf8string utf8str_cis<>; > typedef utf8string utf8str_cs<>; > typedef utf8string utf8str_mixed<>; > > I believe that definitions in Paragraph 18 and in > http://www.nfsv4.org/nfs4_prot.x are wrong and MUST be > typedef opaque utf8string<>; > typedef opaque utf8str_cis<>; > typedef opaque utf8str_cs<>; > typedef opaque utf8str_mixed<>; > (or I really missed something) > > I hope it's not "too late" to change draft-ietf-nfsv4-rfc3010bis-05.txt. > > Thanks, > Sergey > > -- Spencer --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nfs4_prot.x" /* * Copyright (C) The Internet Society (1998-2003). * All Rights Reserved. */ /* * nfs4_prot.x * */ %#pragma ident "@(#)nfs4_prot.x 1.122" /* * Basic typedefs for RFC 1832 data type definitions */ typedef int int32_t; typedef unsigned int uint32_t; typedef hyper int64_t; typedef unsigned hyper uint64_t; /* * Sizes */ const NFS4_FHSIZE = 128; const NFS4_VERIFIER_SIZE = 8; const NFS4_OPAQUE_LIMIT = 1024; /* * File types */ enum nfs_ftype4 { NF4REG = 1, /* Regular File */ NF4DIR = 2, /* Directory */ NF4BLK = 3, /* Special File - block device */ NF4CHR = 4, /* Special File - character device */ NF4LNK = 5, /* Symbolic Link */ NF4SOCK = 6, /* Special File - socket */ NF4FIFO = 7, /* Special File - fifo */ NF4ATTRDIR = 8, /* Attribute Directory */ NF4NAMEDATTR = 9 /* Named Attribute */ }; /* * Error status */ enum nfsstat4 { NFS4_OK = 0, /* everything is okay */ NFS4ERR_PERM = 1, /* caller not privileged */ NFS4ERR_NOENT = 2, /* no such file/directory */ NFS4ERR_IO = 5, /* hard I/O error */ NFS4ERR_NXIO = 6, /* no such device */ NFS4ERR_ACCESS = 13, /* access denied */ NFS4ERR_EXIST = 17, /* file already exists */ NFS4ERR_XDEV = 18, /* different filesystems */ /* Unused/reserved 19 */ NFS4ERR_NOTDIR = 20, /* should be a directory */ NFS4ERR_ISDIR = 21, /* should not be directory */ NFS4ERR_INVAL = 22, /* invalid argument */ NFS4ERR_FBIG = 27, /* file exceeds server max */ NFS4ERR_NOSPC = 28, /* no space on filesystem */ NFS4ERR_ROFS = 30, /* read-only filesystem */ NFS4ERR_MLINK = 31, /* too many hard links */ NFS4ERR_NAMETOOLONG = 63, /* name exceeds server max */ NFS4ERR_NOTEMPTY = 66, /* directory not empty */ NFS4ERR_DQUOT = 69, /* hard quota limit reached*/ NFS4ERR_STALE = 70, /* file no longer exists */ NFS4ERR_BADHANDLE = 10001,/* Illegal filehandle */ NFS4ERR_BAD_COOKIE = 10003,/* READDIR cookie is stale */ NFS4ERR_NOTSUPP = 10004,/* operation not supported */ NFS4ERR_TOOSMALL = 10005,/* response limit exceeded */ NFS4ERR_SERVERFAULT = 10006,/* undefined server error */ NFS4ERR_BADTYPE = 10007,/* type invalid for CREATE */ NFS4ERR_DELAY = 10008,/* file "busy" - retry */ NFS4ERR_SAME = 10009,/* nverify says attrs same */ NFS4ERR_DENIED = 10010,/* lock unavailable */ NFS4ERR_EXPIRED = 10011,/* lock lease expired */ NFS4ERR_LOCKED = 10012,/* I/O failed due to lock */ NFS4ERR_GRACE = 10013,/* in grace period */ NFS4ERR_FHEXPIRED = 10014,/* filehandle expired */ NFS4ERR_SHARE_DENIED = 10015,/* share reserve denied */ NFS4ERR_WRONGSEC = 10016,/* wrong security flavor */ NFS4ERR_CLID_INUSE = 10017,/* clientid in use */ NFS4ERR_RESOURCE = 10018,/* resource exhaustion */ NFS4ERR_MOVED = 10019,/* filesystem relocated */ NFS4ERR_NOFILEHANDLE = 10020,/* current FH is not set */ NFS4ERR_MINOR_VERS_MISMATCH = 10021,/* minor vers not supp */ NFS4ERR_STALE_CLIENTID = 10022,/* server has rebooted */ NFS4ERR_STALE_STATEID = 10023,/* server has rebooted */ NFS4ERR_OLD_STATEID = 10024,/* state is out of sync */ NFS4ERR_BAD_STATEID = 10025,/* incorrect stateid */ NFS4ERR_BAD_SEQID = 10026,/* request is out of seq. */ NFS4ERR_NOT_SAME = 10027,/* verify - attrs not same */ NFS4ERR_LOCK_RANGE = 10028,/* lock range not supported*/ NFS4ERR_SYMLINK = 10029,/* should be file/directory*/ NFS4ERR_RESTOREFH = 10030,/* no saved filehandle */ NFS4ERR_LEASE_MOVED = 10031,/* some filesystem moved */ NFS4ERR_ATTRNOTSUPP = 10032,/* recommended attr not sup*/ NFS4ERR_NO_GRACE = 10033,/* reclaim outside of grace*/ NFS4ERR_RECLAIM_BAD = 10034,/* reclaim error at server */ NFS4ERR_RECLAIM_CONFLICT = 10035,/* conflict on reclaim */ NFS4ERR_BADXDR = 10036,/* XDR decode failed */ NFS4ERR_LOCKS_HELD = 10037,/* file locks held at CLOSE*/ NFS4ERR_OPENMODE = 10038,/* conflict in OPEN and I/O*/ NFS4ERR_BADOWNER = 10039,/* owner translation bad */ NFS4ERR_BADCHAR = 10040,/* utf-8 char not supported*/ NFS4ERR_BADNAME = 10041,/* name not supported */ NFS4ERR_BAD_RANGE = 10042,/* lock range not supported*/ NFS4ERR_LOCK_NOTSUPP = 10043,/* no atomic up/downgrade */ NFS4ERR_OP_ILLEGAL = 10044,/* undefined operation */ NFS4ERR_DEADLOCK = 10045,/* file locking deadlock */ NFS4ERR_FILE_OPEN = 10046,/* open file blocks op. */ NFS4ERR_ADMIN_REVOKED = 10047,/* lockowner state revoked */ NFS4ERR_CB_PATH_DOWN = 10048 /* callback path down */ }; /* * Basic data types */ typedef uint32_t bitmap4<>; typedef uint64_t offset4; typedef uint32_t count4; typedef uint64_t length4; typedef uint64_t clientid4; typedef uint32_t seqid4; typedef opaque utf8string<>; typedef utf8string utf8str_cis; typedef utf8string utf8str_cs; typedef utf8string utf8str_mixed; typedef utf8str_cs component4; typedef component4 pathname4<>; typedef uint64_t nfs_lockid4; typedef uint64_t nfs_cookie4; typedef utf8str_cs linktext4; typedef opaque sec_oid4<>; typedef uint32_t qop4; typedef uint32_t mode4; typedef uint64_t changeid4; typedef opaque verifier4[NFS4_VERIFIER_SIZE]; /* * Timeval */ struct nfstime4 { int64_t seconds; uint32_t nseconds; }; enum time_how4 { SET_TO_SERVER_TIME4 = 0, SET_TO_CLIENT_TIME4 = 1 }; union settime4 switch (time_how4 set_it) { case SET_TO_CLIENT_TIME4: nfstime4 time; default: void; }; /* * File access handle */ typedef opaque nfs_fh4; /* * File attribute definitions */ /* * FSID structure for major/minor */ struct fsid4 { uint64_t major; uint64_t minor; }; /* * Filesystem locations attribute for relocation/migration */ struct fs_location4 { utf8str_cis server<>; pathname4 rootpath; }; struct fs_locations4 { pathname4 fs_root; fs_location4 locations<>; }; /* * Various Access Control Entry definitions */ /* * Mask that indicates which Access Control Entries are supported. * Values for the fattr4_aclsupport attribute. */ const ACL4_SUPPORT_ALLOW_ACL = 0x00000001; const ACL4_SUPPORT_DENY_ACL = 0x00000002; const ACL4_SUPPORT_AUDIT_ACL = 0x00000004; const ACL4_SUPPORT_ALARM_ACL = 0x00000008; typedef uint32_t acetype4; /* * acetype4 values, others can be added as needed. */ const ACE4_ACCESS_ALLOWED_ACE_TYPE = 0x00000000; const ACE4_ACCESS_DENIED_ACE_TYPE = 0x00000001; const ACE4_SYSTEM_AUDIT_ACE_TYPE = 0x00000002; const ACE4_SYSTEM_ALARM_ACE_TYPE = 0x00000003; /* * ACE flag */ typedef uint32_t aceflag4; /* * ACE flag values */ const ACE4_FILE_INHERIT_ACE = 0x00000001; const ACE4_DIRECTORY_INHERIT_ACE = 0x00000002; const ACE4_NO_PROPAGATE_INHERIT_ACE = 0x00000004; const ACE4_INHERIT_ONLY_ACE = 0x00000008; const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG = 0x00000010; const ACE4_FAILED_ACCESS_ACE_FLAG = 0x00000020; const ACE4_IDENTIFIER_GROUP = 0x00000040; /* * ACE mask */ typedef uint32_t acemask4; /* * ACE mask values */ const ACE4_READ_DATA = 0x00000001; const ACE4_LIST_DIRECTORY = 0x00000001; const ACE4_WRITE_DATA = 0x00000002; const ACE4_ADD_FILE = 0x00000002; const ACE4_APPEND_DATA = 0x00000004; const ACE4_ADD_SUBDIRECTORY = 0x00000004; const ACE4_READ_NAMED_ATTRS = 0x00000008; const ACE4_WRITE_NAMED_ATTRS = 0x00000010; const ACE4_EXECUTE = 0x00000020; const ACE4_DELETE_CHILD = 0x00000040; const ACE4_READ_ATTRIBUTES = 0x00000080; const ACE4_WRITE_ATTRIBUTES = 0x00000100; const ACE4_DELETE = 0x00010000; const ACE4_READ_ACL = 0x00020000; const ACE4_WRITE_ACL = 0x00040000; const ACE4_WRITE_OWNER = 0x00080000; const ACE4_SYNCHRONIZE = 0x00100000; /* * ACE4_GENERIC_READ -- defined as combination of * ACE4_READ_ACL | * ACE4_READ_DATA | * ACE4_READ_ATTRIBUTES | * ACE4_SYNCHRONIZE */ const ACE4_GENERIC_READ = 0x00120081; /* * ACE4_GENERIC_WRITE -- defined as combination of * ACE4_READ_ACL | * ACE4_WRITE_DATA | * ACE4_WRITE_ATTRIBUTES | * ACE4_WRITE_ACL | * ACE4_APPEND_DATA | * ACE4_SYNCHRONIZE */ const ACE4_GENERIC_WRITE = 0x00160106; /* * ACE4_GENERIC_EXECUTE -- defined as combination of * ACE4_READ_ACL * ACE4_READ_ATTRIBUTES * ACE4_EXECUTE * ACE4_SYNCHRONIZE */ const ACE4_GENERIC_EXECUTE = 0x001200A0; /* * Access Control Entry definition */ struct nfsace4 { acetype4 type; aceflag4 flag; acemask4 access_mask; utf8str_mixed who; }; /* * Field definitions for the fattr4_mode attribute */ const MODE4_SUID = 0x800; /* set user id on execution */ const MODE4_SGID = 0x400; /* set group id on execution */ const MODE4_SVTX = 0x200; /* save text even after use */ const MODE4_RUSR = 0x100; /* read permission: owner */ const MODE4_WUSR = 0x080; /* write permission: owner */ const MODE4_XUSR = 0x040; /* execute permission: owner */ const MODE4_RGRP = 0x020; /* read permission: group */ const MODE4_WGRP = 0x010; /* write permission: group */ const MODE4_XGRP = 0x008; /* execute permission: group */ const MODE4_ROTH = 0x004; /* read permission: other */ const MODE4_WOTH = 0x002; /* write permission: other */ const MODE4_XOTH = 0x001; /* execute permission: other */ /* * Special data/attribute associated with * file types NF4BLK and NF4CHR. */ struct specdata4 { uint32_t specdata1; /* major device number */ uint32_t specdata2; /* minor device number */ }; /* * Values for fattr4_fh_expire_type */ const FH4_PERSISTENT = 0x00000000; const FH4_NOEXPIRE_WITH_OPEN = 0x00000001; const FH4_VOLATILE_ANY = 0x00000002; const FH4_VOL_MIGRATION = 0x00000004; const FH4_VOL_RENAME = 0x00000008; typedef bitmap4 fattr4_supported_attrs; typedef nfs_ftype4 fattr4_type; typedef uint32_t fattr4_fh_expire_type; typedef changeid4 fattr4_change; typedef uint64_t fattr4_size; typedef bool fattr4_link_support; typedef bool fattr4_symlink_support; typedef bool fattr4_named_attr; typedef fsid4 fattr4_fsid; typedef bool fattr4_unique_handles; typedef uint32_t fattr4_lease_time; typedef nfsstat4 fattr4_rdattr_error; typedef nfsace4 fattr4_acl<>; typedef uint32_t fattr4_aclsupport; typedef bool fattr4_archive; typedef bool fattr4_cansettime; typedef bool fattr4_case_insensitive; typedef bool fattr4_case_preserving; typedef bool fattr4_chown_restricted; typedef uint64_t fattr4_fileid; typedef uint64_t fattr4_files_avail; typedef nfs_fh4 fattr4_filehandle; typedef uint64_t fattr4_files_free; typedef uint64_t fattr4_files_total; typedef fs_locations4 fattr4_fs_locations; typedef bool fattr4_hidden; typedef bool fattr4_homogeneous; typedef uint64_t fattr4_maxfilesize; typedef uint32_t fattr4_maxlink; typedef uint32_t fattr4_maxname; typedef uint64_t fattr4_maxread; typedef uint64_t fattr4_maxwrite; typedef utf8str_cs fattr4_mimetype; typedef mode4 fattr4_mode; typedef uint64_t fattr4_mounted_on_fileid; typedef bool fattr4_no_trunc; typedef uint32_t fattr4_numlinks; typedef utf8str_mixed fattr4_owner; typedef utf8str_mixed fattr4_owner_group; typedef uint64_t fattr4_quota_avail_hard; typedef uint64_t fattr4_quota_avail_soft; typedef uint64_t fattr4_quota_used; typedef specdata4 fattr4_rawdev; typedef uint64_t fattr4_space_avail; typedef uint64_t fattr4_space_free; typedef uint64_t fattr4_space_total; typedef uint64_t fattr4_space_used; typedef bool fattr4_system; typedef nfstime4 fattr4_time_access; typedef settime4 fattr4_time_access_set; typedef nfstime4 fattr4_time_backup; typedef nfstime4 fattr4_time_create; typedef nfstime4 fattr4_time_delta; typedef nfstime4 fattr4_time_metadata; typedef nfstime4 fattr4_time_modify; typedef settime4 fattr4_time_modify_set; /* * Mandatory Attributes */ const FATTR4_SUPPORTED_ATTRS = 0; const FATTR4_TYPE = 1; const FATTR4_FH_EXPIRE_TYPE = 2; const FATTR4_CHANGE = 3; const FATTR4_SIZE = 4; const FATTR4_LINK_SUPPORT = 5; const FATTR4_SYMLINK_SUPPORT = 6; const FATTR4_NAMED_ATTR = 7; const FATTR4_FSID = 8; const FATTR4_UNIQUE_HANDLES = 9; const FATTR4_LEASE_TIME = 10; const FATTR4_RDATTR_ERROR = 11; const FATTR4_FILEHANDLE = 19; /* * Recommended Attributes */ const FATTR4_ACL = 12; const FATTR4_ACLSUPPORT = 13; const FATTR4_ARCHIVE = 14; const FATTR4_CANSETTIME = 15; const FATTR4_CASE_INSENSITIVE = 16; const FATTR4_CASE_PRESERVING = 17; const FATTR4_CHOWN_RESTRICTED = 18; const FATTR4_FILEID = 20; const FATTR4_FILES_AVAIL = 21; const FATTR4_FILES_FREE = 22; const FATTR4_FILES_TOTAL = 23; const FATTR4_FS_LOCATIONS = 24; const FATTR4_HIDDEN = 25; const FATTR4_HOMOGENEOUS = 26; const FATTR4_MAXFILESIZE = 27; const FATTR4_MAXLINK = 28; const FATTR4_MAXNAME = 29; const FATTR4_MAXREAD = 30; const FATTR4_MAXWRITE = 31; const FATTR4_MIMETYPE = 32; const FATTR4_MODE = 33; const FATTR4_NO_TRUNC = 34; const FATTR4_NUMLINKS = 35; const FATTR4_OWNER = 36; const FATTR4_OWNER_GROUP = 37; const FATTR4_QUOTA_AVAIL_HARD = 38; const FATTR4_QUOTA_AVAIL_SOFT = 39; const FATTR4_QUOTA_USED = 40; const FATTR4_RAWDEV = 41; const FATTR4_SPACE_AVAIL = 42; const FATTR4_SPACE_FREE = 43; const FATTR4_SPACE_TOTAL = 44; const FATTR4_SPACE_USED = 45; const FATTR4_SYSTEM = 46; const FATTR4_TIME_ACCESS = 47; const FATTR4_TIME_ACCESS_SET = 48; const FATTR4_TIME_BACKUP = 49; const FATTR4_TIME_CREATE = 50; const FATTR4_TIME_DELTA = 51; const FATTR4_TIME_METADATA = 52; const FATTR4_TIME_MODIFY = 53; const FATTR4_TIME_MODIFY_SET = 54; const FATTR4_MOUNTED_ON_FILEID = 55; typedef opaque attrlist4<>; /* * File attribute container */ struct fattr4 { bitmap4 attrmask; attrlist4 attr_vals; }; /* * Change info for the client */ struct change_info4 { bool atomic; changeid4 before; changeid4 after; }; struct clientaddr4 { /* see struct rpcb in RFC 1833 */ string r_netid<>; /* network id */ string r_addr<>; /* universal address */ }; /* * Callback program info as provided by the client */ struct cb_client4 { uint32_t cb_program; clientaddr4 cb_location; }; /* * Stateid */ struct stateid4 { uint32_t seqid; opaque other[12]; }; /* * Client ID */ struct nfs_client_id4 { verifier4 verifier; opaque id; }; struct open_owner4 { clientid4 clientid; opaque owner; }; struct lock_owner4 { clientid4 clientid; opaque owner; }; enum nfs_lock_type4 { READ_LT = 1, WRITE_LT = 2, READW_LT = 3, /* blocking read */ WRITEW_LT = 4 /* blocking write */ }; /* * ACCESS: Check access permission */ const ACCESS4_READ = 0x00000001; const ACCESS4_LOOKUP = 0x00000002; const ACCESS4_MODIFY = 0x00000004; const ACCESS4_EXTEND = 0x00000008; const ACCESS4_DELETE = 0x00000010; const ACCESS4_EXECUTE = 0x00000020; struct ACCESS4args { /* CURRENT_FH: object */ uint32_t access; }; struct ACCESS4resok { uint32_t supported; uint32_t access; }; union ACCESS4res switch (nfsstat4 status) { case NFS4_OK: ACCESS4resok resok4; default: void; }; /* * CLOSE: Close a file and release share reservations */ struct CLOSE4args { /* CURRENT_FH: object */ seqid4 seqid; stateid4 open_stateid; }; union CLOSE4res switch (nfsstat4 status) { case NFS4_OK: stateid4 open_stateid; default: void; }; /* * COMMIT: Commit cached data on server to stable storage */ struct COMMIT4args { /* CURRENT_FH: file */ offset4 offset; count4 count; }; struct COMMIT4resok { verifier4 writeverf; }; union COMMIT4res switch (nfsstat4 status) { case NFS4_OK: COMMIT4resok resok4; default: void; }; /* * CREATE: Create a non-regular file */ union createtype4 switch (nfs_ftype4 type) { case NF4LNK: linktext4 linkdata; case NF4BLK: case NF4CHR: specdata4 devdata; case NF4SOCK: case NF4FIFO: case NF4DIR: void; default: void; /* server should return NFS4ERR_BADTYPE */ }; struct CREATE4args { /* CURRENT_FH: directory for creation */ createtype4 objtype; component4 objname; fattr4 createattrs; }; struct CREATE4resok { change_info4 cinfo; bitmap4 attrset; /* attributes set */ }; union CREATE4res switch (nfsstat4 status) { case NFS4_OK: CREATE4resok resok4; default: void; }; /* * DELEGPURGE: Purge Delegations Awaiting Recovery */ struct DELEGPURGE4args { clientid4 clientid; }; struct DELEGPURGE4res { nfsstat4 status; }; /* * DELEGRETURN: Return a delegation */ struct DELEGRETURN4args { /* CURRENT_FH: delegated file */ stateid4 deleg_stateid; }; struct DELEGRETURN4res { nfsstat4 status; }; /* * GETATTR: Get file attributes */ struct GETATTR4args { /* CURRENT_FH: directory or file */ bitmap4 attr_request; }; struct GETATTR4resok { fattr4 obj_attributes; }; union GETATTR4res switch (nfsstat4 status) { case NFS4_OK: GETATTR4resok resok4; default: void; }; /* * GETFH: Get current filehandle */ struct GETFH4resok { nfs_fh4 object; }; union GETFH4res switch (nfsstat4 status) { case NFS4_OK: GETFH4resok resok4; default: void; }; /* * LINK: Create link to an object */ struct LINK4args { /* SAVED_FH: source object */ /* CURRENT_FH: target directory */ component4 newname; }; struct LINK4resok { change_info4 cinfo; }; union LINK4res switch (nfsstat4 status) { case NFS4_OK: LINK4resok resok4; default: void; }; /* * For LOCK, transition from open_owner to new lock_owner */ struct open_to_lock_owner4 { seqid4 open_seqid; stateid4 open_stateid; seqid4 lock_seqid; lock_owner4 lock_owner; }; /* * For LOCK, existing lock_owner continues to request file locks */ struct exist_lock_owner4 { stateid4 lock_stateid; seqid4 lock_seqid; }; union locker4 switch (bool new_lock_owner) { case TRUE: open_to_lock_owner4 open_owner; case FALSE: exist_lock_owner4 lock_owner; }; /* * LOCK/LOCKT/LOCKU: Record lock management */ struct LOCK4args { /* CURRENT_FH: file */ nfs_lock_type4 locktype; bool reclaim; offset4 offset; length4 length; locker4 locker; }; struct LOCK4denied { offset4 offset; length4 length; nfs_lock_type4 locktype; lock_owner4 owner; }; struct LOCK4resok { stateid4 lock_stateid; }; union LOCK4res switch (nfsstat4 status) { case NFS4_OK: LOCK4resok resok4; case NFS4ERR_DENIED: LOCK4denied denied; default: void; }; struct LOCKT4args { /* CURRENT_FH: file */ nfs_lock_type4 locktype; offset4 offset; length4 length; lock_owner4 owner; }; union LOCKT4res switch (nfsstat4 status) { case NFS4ERR_DENIED: LOCK4denied denied; case NFS4_OK: void; default: void; }; struct LOCKU4args { /* CURRENT_FH: file */ nfs_lock_type4 locktype; seqid4 seqid; stateid4 lock_stateid; offset4 offset; length4 length; }; union LOCKU4res switch (nfsstat4 status) { case NFS4_OK: stateid4 lock_stateid; default: void; }; /* * LOOKUP: Lookup filename */ struct LOOKUP4args { /* CURRENT_FH: directory */ component4 objname; }; struct LOOKUP4res { /* CURRENT_FH: object */ nfsstat4 status; }; /* * LOOKUPP: Lookup parent directory */ struct LOOKUPP4res { /* CURRENT_FH: directory */ nfsstat4 status; }; /* * NVERIFY: Verify attributes different */ struct NVERIFY4args { /* CURRENT_FH: object */ fattr4 obj_attributes; }; struct NVERIFY4res { nfsstat4 status; }; /* * Various definitions for OPEN */ enum createmode4 { UNCHECKED4 = 0, GUARDED4 = 1, EXCLUSIVE4 = 2 }; union createhow4 switch (createmode4 mode) { case UNCHECKED4: case GUARDED4: fattr4 createattrs; case EXCLUSIVE4: verifier4 createverf; }; enum opentype4 { OPEN4_NOCREATE = 0, OPEN4_CREATE = 1 }; union openflag4 switch (opentype4 opentype) { case OPEN4_CREATE: createhow4 how; default: void; }; /* Next definitions used for OPEN delegation */ enum limit_by4 { NFS_LIMIT_SIZE = 1, NFS_LIMIT_BLOCKS = 2 /* others as needed */ }; struct nfs_modified_limit4 { uint32_t num_blocks; uint32_t bytes_per_block; }; union nfs_space_limit4 switch (limit_by4 limitby) { /* limit specified as file size */ case NFS_LIMIT_SIZE: uint64_t filesize; /* limit specified by number of blocks */ case NFS_LIMIT_BLOCKS: nfs_modified_limit4 mod_blocks; } ; /* * Share Access and Deny constants for open argument */ const OPEN4_SHARE_ACCESS_READ = 0x00000001; const OPEN4_SHARE_ACCESS_WRITE = 0x00000002; const OPEN4_SHARE_ACCESS_BOTH = 0x00000003; const OPEN4_SHARE_DENY_NONE = 0x00000000; const OPEN4_SHARE_DENY_READ = 0x00000001; const OPEN4_SHARE_DENY_WRITE = 0x00000002; const OPEN4_SHARE_DENY_BOTH = 0x00000003; enum open_delegation_type4 { OPEN_DELEGATE_NONE = 0, OPEN_DELEGATE_READ = 1, OPEN_DELEGATE_WRITE = 2 }; enum open_claim_type4 { CLAIM_NULL = 0, CLAIM_PREVIOUS = 1, CLAIM_DELEGATE_CUR = 2, CLAIM_DELEGATE_PREV = 3 }; struct open_claim_delegate_cur4 { stateid4 delegate_stateid; component4 file; }; union open_claim4 switch (open_claim_type4 claim) { /* * No special rights to file. Ordinary OPEN of the specified file. */ case CLAIM_NULL: /* CURRENT_FH: directory */ component4 file; /* * Right to the file established by an open previous to server * reboot. File identified by filehandle obtained at that time * rather than by name. */ case CLAIM_PREVIOUS: /* CURRENT_FH: file being reclaimed */ open_delegation_type4 delegate_type; /* * Right to file based on a delegation granted by the server. * File is specified by name. */ case CLAIM_DELEGATE_CUR: /* CURRENT_FH: directory */ open_claim_delegate_cur4 delegate_cur_info; /* Right to file based on a delegation granted to a previous boot * instance of the client. File is specified by name. */ case CLAIM_DELEGATE_PREV: /* CURRENT_FH: directory */ component4 file_delegate_prev; }; /* * OPEN: Open a file, potentially receiving an open delegation */ struct OPEN4args { seqid4 seqid; uint32_t share_access; uint32_t share_deny; open_owner4 owner; openflag4 openhow; open_claim4 claim; }; struct open_read_delegation4 { stateid4 stateid; /* Stateid for delegation*/ bool recall; /* Pre-recalled flag for delegations obtained by reclaim (CLAIM_PREVIOUS) */ nfsace4 permissions; /* Defines users who don't need an ACCESS call to open for read */ }; struct open_write_delegation4 { stateid4 stateid; /* Stateid for delegation */ bool recall; /* Pre-recalled flag for delegations obtained by reclaim (CLAIM_PREVIOUS) */ nfs_space_limit4 space_limit; /* Defines condition that the client must check to determine whether the file needs to be flushed to the server on close. */ nfsace4 permissions; /* Defines users who don't need an ACCESS call as part of a delegated open. */ }; union open_delegation4 switch (open_delegation_type4 delegation_type) { case OPEN_DELEGATE_NONE: void; case OPEN_DELEGATE_READ: open_read_delegation4 read; case OPEN_DELEGATE_WRITE: open_write_delegation4 write; }; /* * Result flags */ /* Client must confirm open */ const OPEN4_RESULT_CONFIRM = 0x00000002; /* Type of file locking behavior at the server */ const OPEN4_RESULT_LOCKTYPE_POSIX = 0x00000004; struct OPEN4resok { stateid4 stateid; /* Stateid for open */ change_info4 cinfo; /* Directory Change Info */ uint32_t rflags; /* Result flags */ bitmap4 attrset; /* attribute set for create*/ open_delegation4 delegation; /* Info on any open delegation */ }; union OPEN4res switch (nfsstat4 status) { case NFS4_OK: /* CURRENT_FH: opened file */ OPEN4resok resok4; default: void; }; /* * OPENATTR: open named attributes directory */ struct OPENATTR4args { /* CURRENT_FH: object */ bool createdir; }; struct OPENATTR4res { /* CURRENT_FH: named attr directory */ nfsstat4 status; }; /* * OPEN_CONFIRM: confirm the open */ struct OPEN_CONFIRM4args { /* CURRENT_FH: opened file */ stateid4 open_stateid; seqid4 seqid; }; struct OPEN_CONFIRM4resok { stateid4 open_stateid; }; union OPEN_CONFIRM4res switch (nfsstat4 status) { case NFS4_OK: OPEN_CONFIRM4resok resok4; default: void; }; /* * OPEN_DOWNGRADE: downgrade the access/deny for a file */ struct OPEN_DOWNGRADE4args { /* CURRENT_FH: opened file */ stateid4 open_stateid; seqid4 seqid; uint32_t share_access; uint32_t share_deny; }; struct OPEN_DOWNGRADE4resok { stateid4 open_stateid; }; union OPEN_DOWNGRADE4res switch(nfsstat4 status) { case NFS4_OK: OPEN_DOWNGRADE4resok resok4; default: void; }; /* * PUTFH: Set current filehandle */ struct PUTFH4args { nfs_fh4 object; }; struct PUTFH4res { /* CURRENT_FH: */ nfsstat4 status; }; /* * PUTPUBFH: Set public filehandle */ struct PUTPUBFH4res { /* CURRENT_FH: public fh */ nfsstat4 status; }; /* * PUTROOTFH: Set root filehandle */ struct PUTROOTFH4res { /* CURRENT_FH: root fh */ nfsstat4 status; }; /* * READ: Read from file */ struct READ4args { /* CURRENT_FH: file */ stateid4 stateid; offset4 offset; count4 count; }; struct READ4resok { bool eof; opaque data<>; }; union READ4res switch (nfsstat4 status) { case NFS4_OK: READ4resok resok4; default: void; }; /* * READDIR: Read directory */ struct READDIR4args { /* CURRENT_FH: directory */ nfs_cookie4 cookie; verifier4 cookieverf; count4 dircount; count4 maxcount; bitmap4 attr_request; }; struct entry4 { nfs_cookie4 cookie; component4 name; fattr4 attrs; entry4 *nextentry; }; struct dirlist4 { entry4 *entries; bool eof; }; struct READDIR4resok { verifier4 cookieverf; dirlist4 reply; }; union READDIR4res switch (nfsstat4 status) { case NFS4_OK: READDIR4resok resok4; default: void; }; /* * READLINK: Read symbolic link */ struct READLINK4resok { linktext4 link; }; union READLINK4res switch (nfsstat4 status) { case NFS4_OK: READLINK4resok resok4; default: void; }; /* * REMOVE: Remove filesystem object */ struct REMOVE4args { /* CURRENT_FH: directory */ component4 target; }; struct REMOVE4resok { change_info4 cinfo; }; union REMOVE4res switch (nfsstat4 status) { case NFS4_OK: REMOVE4resok resok4; default: void; }; /* * RENAME: Rename directory entry */ struct RENAME4args { /* SAVED_FH: source directory */ component4 oldname; /* CURRENT_FH: target directory */ component4 newname; }; struct RENAME4resok { change_info4 source_cinfo; change_info4 target_cinfo; }; union RENAME4res switch (nfsstat4 status) { case NFS4_OK: RENAME4resok resok4; default: void; }; /* * RENEW: Renew a Lease */ struct RENEW4args { clientid4 clientid; }; struct RENEW4res { nfsstat4 status; }; /* * RESTOREFH: Restore saved filehandle */ struct RESTOREFH4res { /* CURRENT_FH: value of saved fh */ nfsstat4 status; }; /* * SAVEFH: Save current filehandle */ struct SAVEFH4res { /* SAVED_FH: value of current fh */ nfsstat4 status; }; /* * SECINFO: Obtain Available Security Mechanisms */ struct SECINFO4args { /* CURRENT_FH: directory */ component4 name; }; /* * From RFC 2203 */ enum rpc_gss_svc_t { RPC_GSS_SVC_NONE = 1, RPC_GSS_SVC_INTEGRITY = 2, RPC_GSS_SVC_PRIVACY = 3 }; struct rpcsec_gss_info { sec_oid4 oid; qop4 qop; rpc_gss_svc_t service; }; /* RPCSEC_GSS has a value of '6' - See RFC 2203 */ union secinfo4 switch (uint32_t flavor) { case RPCSEC_GSS: rpcsec_gss_info flavor_info; default: void; }; typedef secinfo4 SECINFO4resok<>; union SECINFO4res switch (nfsstat4 status) { case NFS4_OK: SECINFO4resok resok4; default: void; }; /* * SETATTR: Set attributes */ struct SETATTR4args { /* CURRENT_FH: target object */ stateid4 stateid; fattr4 obj_attributes; }; struct SETATTR4res { nfsstat4 status; bitmap4 attrsset; }; /* * SETCLIENTID */ struct SETCLIENTID4args { nfs_client_id4 client; cb_client4 callback; uint32_t callback_ident; }; struct SETCLIENTID4resok { clientid4 clientid; verifier4 setclientid_confirm; }; union SETCLIENTID4res switch (nfsstat4 status) { case NFS4_OK: SETCLIENTID4resok resok4; case NFS4ERR_CLID_INUSE: clientaddr4 client_using; default: void; }; struct SETCLIENTID_CONFIRM4args { clientid4 clientid; verifier4 setclientid_confirm; }; struct SETCLIENTID_CONFIRM4res { nfsstat4 status; }; /* * VERIFY: Verify attributes same */ struct VERIFY4args { /* CURRENT_FH: object */ fattr4 obj_attributes; }; struct VERIFY4res { nfsstat4 status; }; /* * WRITE: Write to file */ enum stable_how4 { UNSTABLE4 = 0, DATA_SYNC4 = 1, FILE_SYNC4 = 2 }; struct WRITE4args { /* CURRENT_FH: file */ stateid4 stateid; offset4 offset; stable_how4 stable; opaque data<>; }; struct WRITE4resok { count4 count; stable_how4 committed; verifier4 writeverf; }; union WRITE4res switch (nfsstat4 status) { case NFS4_OK: WRITE4resok resok4; default: void; }; /* * RELEASE_LOCKOWNER: Notify server to release lockowner */ struct RELEASE_LOCKOWNER4args { lock_owner4 lock_owner; }; struct RELEASE_LOCKOWNER4res { nfsstat4 status; }; /* * ILLEGAL: Response for illegal operation numbers */ struct ILLEGAL4res { nfsstat4 status; }; /* * Operation arrays */ enum nfs_opnum4 { OP_ACCESS = 3, OP_CLOSE = 4, OP_COMMIT = 5, OP_CREATE = 6, OP_DELEGPURGE = 7, OP_DELEGRETURN = 8, OP_GETATTR = 9, OP_GETFH = 10, OP_LINK = 11, OP_LOCK = 12, OP_LOCKT = 13, OP_LOCKU = 14, OP_LOOKUP = 15, OP_LOOKUPP = 16, OP_NVERIFY = 17, OP_OPEN = 18, OP_OPENATTR = 19, OP_OPEN_CONFIRM = 20, OP_OPEN_DOWNGRADE = 21, OP_PUTFH = 22, OP_PUTPUBFH = 23, OP_PUTROOTFH = 24, OP_READ = 25, OP_READDIR = 26, OP_READLINK = 27, OP_REMOVE = 28, OP_RENAME = 29, OP_RENEW = 30, OP_RESTOREFH = 31, OP_SAVEFH = 32, OP_SECINFO = 33, OP_SETATTR = 34, OP_SETCLIENTID = 35, OP_SETCLIENTID_CONFIRM = 36, OP_VERIFY = 37, OP_WRITE = 38, OP_RELEASE_LOCKOWNER = 39, OP_ILLEGAL = 10044 }; union nfs_argop4 switch (nfs_opnum4 argop) { case OP_ACCESS: ACCESS4args opaccess; case OP_CLOSE: CLOSE4args opclose; case OP_COMMIT: COMMIT4args opcommit; case OP_CREATE: CREATE4args opcreate; case OP_DELEGPURGE: DELEGPURGE4args opdelegpurge; case OP_DELEGRETURN: DELEGRETURN4args opdelegreturn; case OP_GETATTR: GETATTR4args opgetattr; case OP_GETFH: void; case OP_LINK: LINK4args oplink; case OP_LOCK: LOCK4args oplock; case OP_LOCKT: LOCKT4args oplockt; case OP_LOCKU: LOCKU4args oplocku; case OP_LOOKUP: LOOKUP4args oplookup; case OP_LOOKUPP: void; case OP_NVERIFY: NVERIFY4args opnverify; case OP_OPEN: OPEN4args opopen; case OP_OPENATTR: OPENATTR4args opopenattr; case OP_OPEN_CONFIRM: OPEN_CONFIRM4args opopen_confirm; case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4args opopen_downgrade; case OP_PUTFH: PUTFH4args opputfh; case OP_PUTPUBFH: void; case OP_PUTROOTFH: void; case OP_READ: READ4args opread; case OP_READDIR: READDIR4args opreaddir; case OP_READLINK: void; case OP_REMOVE: REMOVE4args opremove; case OP_RENAME: RENAME4args oprename; case OP_RENEW: RENEW4args oprenew; case OP_RESTOREFH: void; case OP_SAVEFH: void; case OP_SECINFO: SECINFO4args opsecinfo; case OP_SETATTR: SETATTR4args opsetattr; case OP_SETCLIENTID: SETCLIENTID4args opsetclientid; case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4args opsetclientid_confirm; case OP_VERIFY: VERIFY4args opverify; case OP_WRITE: WRITE4args opwrite; case OP_RELEASE_LOCKOWNER: RELEASE_LOCKOWNER4args oprelease_lockowner; case OP_ILLEGAL: void; }; union nfs_resop4 switch (nfs_opnum4 resop){ case OP_ACCESS: ACCESS4res opaccess; case OP_CLOSE: CLOSE4res opclose; case OP_COMMIT: COMMIT4res opcommit; case OP_CREATE: CREATE4res opcreate; case OP_DELEGPURGE: DELEGPURGE4res opdelegpurge; case OP_DELEGRETURN: DELEGRETURN4res opdelegreturn; case OP_GETATTR: GETATTR4res opgetattr; case OP_GETFH: GETFH4res opgetfh; case OP_LINK: LINK4res oplink; case OP_LOCK: LOCK4res oplock; case OP_LOCKT: LOCKT4res oplockt; case OP_LOCKU: LOCKU4res oplocku; case OP_LOOKUP: LOOKUP4res oplookup; case OP_LOOKUPP: LOOKUPP4res oplookupp; case OP_NVERIFY: NVERIFY4res opnverify; case OP_OPEN: OPEN4res opopen; case OP_OPENATTR: OPENATTR4res opopenattr; case OP_OPEN_CONFIRM: OPEN_CONFIRM4res opopen_confirm; case OP_OPEN_DOWNGRADE: OPEN_DOWNGRADE4res opopen_downgrade; case OP_PUTFH: PUTFH4res opputfh; case OP_PUTPUBFH: PUTPUBFH4res opputpubfh; case OP_PUTROOTFH: PUTROOTFH4res opputrootfh; case OP_READ: READ4res opread; case OP_READDIR: READDIR4res opreaddir; case OP_READLINK: READLINK4res opreadlink; case OP_REMOVE: REMOVE4res opremove; case OP_RENAME: RENAME4res oprename; case OP_RENEW: RENEW4res oprenew; case OP_RESTOREFH: RESTOREFH4res oprestorefh; case OP_SAVEFH: SAVEFH4res opsavefh; case OP_SECINFO: SECINFO4res opsecinfo; case OP_SETATTR: SETATTR4res opsetattr; case OP_SETCLIENTID: SETCLIENTID4res opsetclientid; case OP_SETCLIENTID_CONFIRM: SETCLIENTID_CONFIRM4res opsetclientid_confirm; case OP_VERIFY: VERIFY4res opverify; case OP_WRITE: WRITE4res opwrite; case OP_RELEASE_LOCKOWNER: RELEASE_LOCKOWNER4res oprelease_lockowner; case OP_ILLEGAL: ILLEGAL4res opillegal; }; struct COMPOUND4args { utf8str_cs tag; uint32_t minorversion; nfs_argop4 argarray<>; }; struct COMPOUND4res { nfsstat4 status; utf8str_cs tag; nfs_resop4 resarray<>; }; /* * Remote file service routines */ program NFS4_PROGRAM { version NFS_V4 { void NFSPROC4_NULL(void) = 0; COMPOUND4res NFSPROC4_COMPOUND(COMPOUND4args) = 1; } = 4; } = 100003; /* * NFS4 Callback Procedure Definitions and Program */ /* * CB_GETATTR: Get Current Attributes */ struct CB_GETATTR4args { nfs_fh4 fh; bitmap4 attr_request; }; struct CB_GETATTR4resok { fattr4 obj_attributes; }; union CB_GETATTR4res switch (nfsstat4 status) { case NFS4_OK: CB_GETATTR4resok resok4; default: void; }; /* * CB_RECALL: Recall an Open Delegation */ struct CB_RECALL4args { stateid4 stateid; bool truncate; nfs_fh4 fh; }; struct CB_RECALL4res { nfsstat4 status; }; /* * CB_ILLEGAL: Response for illegal operation numbers */ struct CB_ILLEGAL4res { nfsstat4 status; }; /* * Various definitions for CB_COMPOUND */ enum nfs_cb_opnum4 { OP_CB_GETATTR = 3, OP_CB_RECALL = 4, OP_CB_ILLEGAL = 10044 }; union nfs_cb_argop4 switch (unsigned argop) { case OP_CB_GETATTR: CB_GETATTR4args opcbgetattr; case OP_CB_RECALL: CB_RECALL4args opcbrecall; case OP_CB_ILLEGAL: void; }; union nfs_cb_resop4 switch (unsigned resop){ case OP_CB_GETATTR: CB_GETATTR4res opcbgetattr; case OP_CB_RECALL: CB_RECALL4res opcbrecall; case OP_CB_ILLEGAL: CB_ILLEGAL4res opcbillegal; }; struct CB_COMPOUND4args { utf8str_cs tag; uint32_t minorversion; uint32_t callback_ident; nfs_cb_argop4 argarray<>; }; struct CB_COMPOUND4res { nfsstat4 status; utf8str_cs tag; nfs_cb_resop4 resarray<>; }; /* * Program number is in the transient range since the client * will assign the exact transient program number and provide * that to the server via the SETCLIENTID operation. */ program NFS4_CALLBACK { version NFS_CB { void CB_NULL(void) = 0; CB_COMPOUND4res CB_COMPOUND(CB_COMPOUND4args) = 1; } = 1; } = 0x40000000; --2B/JsCI69OhZNC5r-- From owner-nfsv4-wg@sunroof.eng.sun.com Fri Feb 7 17:20:45 2003 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23309 for ; Fri, 7 Feb 2003 17:20:45 -0500 (EST) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07696; Fri, 7 Feb 2003 14:16:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17MFoVK027195; Fri, 7 Feb 2003 14:15:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17MFcQb012579 for ; Fri, 7 Feb 2003 14:15:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17MFclJ012578 for nfsv4-wg-dist; Fri, 7 Feb 2003 14:15:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17MFbQb012571 for ; Fri, 7 Feb 2003 14:15:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17MFjVL002062 for ; Fri, 7 Feb 2003 14:15:45 -0800 (PST) Received: from maho3msx2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18279 for ; Fri, 7 Feb 2003 15:15:40 -0700 (MST) From: Dai_Peng@emc.com Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <1PRJ38GN>; Fri, 7 Feb 2003 17:15:39 -0500 Message-ID: <6335CBB2F69AD411AD3100D0B7BA38E30CF0BF66@CORPUSMX2> To: spencer.shepler@sun.com, nfsv4-wg@sunroof.eng.sun.com Subject: RE: LOOKUPP and NFS4ERR_WRONGSEC Date: Fri, 7 Feb 2003 17:15:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 694 Lines: 17 > > Not an oversight. The assumption is that if a object in the server's > namespace requires a particular security mechanism for access that all > ancestors of that object will accept the same security mechanism. > This allows a client to use a single security mechanism while > traversing the namespace to that node. It also avoids the problem > that you thought might exist. What you are effectively saying is any v4 compliant server implementation MUST require a nested export to be more restrictive than its parent exports. IMHO, the protocol should not place a limit on the way security policy is administered, although I can see the assumption makes sense most of the time. Peng From owner-nfsv4-wg@sunroof.eng.sun.com Fri Feb 7 17:23:59 2003 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23398 for ; Fri, 7 Feb 2003 17:23:59 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22450; Fri, 7 Feb 2003 15:24:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.SFBay.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17MO0VL004515; Fri, 7 Feb 2003 14:24:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17MNnQb012609 for ; Fri, 7 Feb 2003 14:23:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h17MNnx0012608 for nfsv4-wg-dist; Fri, 7 Feb 2003 14:23:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-nfsv4-wg@sunroof.eng.sun.com using -f Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.Central.Sun.COM [129.147.62.14]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h17MNlQb012601 for ; Fri, 7 Feb 2003 14:23:47 -0800 (PST) Received: from dhcp-uaus08-128-228.Central.Sun.COM (dhcp-uaus08-128-228.Central.Sun.COM [129.153.128.228]) by centralmail2brm.Central.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h17MNtln000137 for ; Fri, 7 Feb 2003 15:23:55 -0700 (MST) Received: from dhcp-uaus08-128-228.Central.Sun.COM (localhost [127.0.0.1]) by dhcp-uaus08-128-228.Central.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h17MLafM100646 for ; Fri, 7 Feb 2003 16:21:36 -0600 (CST) Received: (from shepler@localhost) by dhcp-uaus08-128-228.Central.Sun.COM (8.12.7+Sun/8.12.7/Submit) id h17MLaWr100645 for nfsv4-wg@sunroof.eng.sun.com; Fri, 7 Feb 2003 16:21:36 -0600 (CST) Date: Fri, 7 Feb 2003 16:21:36 -0600 From: Spencer Shepler To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: LOOKUPP and NFS4ERR_WRONGSEC Message-ID: <20030207222136.GS100365@dhcp-uaus08-128-228.central.sun.com> Reply-To: spencer.shepler@sun.com Mail-Followup-To: Spencer Shepler , nfsv4-wg@sunroof.eng.sun.com References: <6335CBB2F69AD411AD3100D0B7BA38E30CF0BF66@CORPUSMX2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6335CBB2F69AD411AD3100D0B7BA38E30CF0BF66@CORPUSMX2> User-Agent: Mutt/1.4i Sender: owner-nfsv4-wg@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO Content-Length: 1271 Lines: 30 On Fri, Dai_Peng@emc.com wrote: > > > > Not an oversight. The assumption is that if a object in the server's > > namespace requires a particular security mechanism for access that all > > ancestors of that object will accept the same security mechanism. > > This allows a client to use a single security mechanism while > > traversing the namespace to that node. It also avoids the pr