From: Chuck Lever Subject: Re: mount.nfs: access denied by server Date: Tue, 25 Aug 2009 15:05:01 -0400 Message-ID: <71C3EBAF-16C4-4353-8C12-266E60BA6907@oracle.com> References: <20090821213016.GG23529@fieldses.org> <1250890836.5700.19.camel@heimdal.trondhjem.org> <20090821214720.GH23529@fieldses.org> <1250891463.5700.21.camel@heimdal.trondhjem.org> <20090824161004.GB4985@fieldses.org> <1251133618.6325.262.camel@heimdal.trondhjem.org> <20090824174129.GD4985@fieldses.org> <1EEDD90B-709F-4C78-97B4-6107AE100162@oracle.com> <4A94162C.20904@sun.com> <95D9E216-A5E5-4B4F-AB50-2724AD5E8C96@oracle.com> <20090825181025.GA29051@fieldses.org> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Cc: Tom Haynes , NFS list To: "J. Bruce Fields" , Trond Myklebust Return-path: Received: from rcsinet12.oracle.com ([148.87.113.124]:25145 "EHLO rgminet12.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755459AbZHYTFM (ORCPT ); Tue, 25 Aug 2009 15:05:12 -0400 In-Reply-To: <20090825181025.GA29051@fieldses.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Aug 25, 2009, at 2:10 PM, J. Bruce Fields wrote: > On Tue, Aug 25, 2009 at 01:40:44PM -0400, Chuck Lever wrote: >> On Aug 25, 2009, at 12:49 PM, Tom Haynes wrote: >>> The MOUNT Version 3 protocol, associated with NFS Version 3, solves >>> the problem by having the response to the MNT procedure include a >>> list of flavors in the MNT procedure. Note that because some NFS >>> servers will export file systems to specific lists of clients, with >>> different access (read-only versus read-write), and with different >>> security flavors, it is possible a client might get back multiple >>> security flavors in the list returned in the MNT response. The use >>> of >>> one flavor instead of another might imply read-only instead of read- >>> write access, or perhaps some other degradation of access. For this >>> reason, a NFS client SHOULD use the first flavor in the list that it >>> supports, on the assumption that the best access is provided by the >>> first flavor. NFS servers that support the ability to export file >>> systems with multiple security flavors SHOULD either present the >>> best >>> accessing flavor first to the client, or leave the order under the >>> control of the system administrator. >>> >>> >>> >>> It sounds pretty clear, >> >> Depends on how you define "best access." Besides there's no >> indication >> in the returned list of whether the access granted by the server >> will be >> r/w, r/o, or what. > > For that reason, all servers I know of have decided to leave the "best > access" decision to the server administrator. > >>> the server SHOULD order them in some fashion and the client SHOULD >>> pick the first one it supports in the list. It is not 'MUST', but if >>> all servers and clients follow the same >>> algorithm, it becomes accepted practice. >> >> There was a reason for picking the last one on the list rather than >> the >> first, but I don't remember what it was. Clients ought to behave >> consistently across implementations, but we unfortunately have some >> behavioral precedents. > > Yes, and we need some workarounds for those, as previously discussed, > but the above-quoted SHOULD can still be mostly honored. I appreciate the use cases Tom posted, but given that our server sometimes tries to compensate for the "use the last flavor listed" behavior of some clients, I would like to understand better what our kernel client needs to do. Perhaps we should discuss this in person. >>> Having said that, our nfssec(5) states that a client can pick any of >>> the modes in the list. >>> >>> But our server returns them in the order entered in the share by the >>> admin. >> >> Which seems like it too ignores the 2623 prescription...? > > We declare the ordering a policy issue and leave it to the server > administrator. The linux server does this as well, and the behavior > is > documented in the exports(5) man page. > > --b. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com