From owner-freebsd-fs@FreeBSD.ORG Thu May 10 20:34:17 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F0AC106566C for ; Thu, 10 May 2012 20:34:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 28E108FC0C for ; Thu, 10 May 2012 20:34:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAGMlrE+DaFvO/2dsb2JhbABEhXavMIIVAQEEASNWBRYOCgICDRkCWQYTiAkFqFiTAYEviWOFBYEYBJV9kECDBQ X-IronPort-AV: E=Sophos;i="4.75,566,1330923600"; d="scan'208";a="168766046" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 10 May 2012 16:34:16 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DE70F7941E; Thu, 10 May 2012 16:34:15 -0400 (EDT) Date: Thu, 10 May 2012 16:34:15 -0400 (EDT) From: Rick Macklem To: Andrey Simonenko Message-ID: <901330725.234130.1336682055896.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120510130731.GA72837@pm513-1.comsys.ntu-kpi.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 20:34:17 -0000 Andrey Simonenko wrote: > On Mon, May 07, 2012 at 07:40:18PM -0400, Rick Macklem wrote: > > Andrey Simonenko wrote: > > > On Sun, Apr 29, 2012 at 04:36:03PM -0400, Rick Macklem wrote: > > > > > > > > Also, be sure to check "man nfsv4" and maybe reference it (it is > > > > currently > > > > in the See Also list, but that might not be strong enough). > > > > > > There is another question not explained in documentation (I could > > > not > > > find the answer at least). Currently NFSv3 client uses reserved > > > port > > > for NFS mounts and uses non reserved port if "noresvport" is > > > specified. > > > NFSv4 client always uses non reserved port, ignoring the > > > "resvport" > > > option in the mount_nfs command. > > > > > > Such behaviour of NFS client was introduced in 1.18 version of > > > fs/nfsclient/nfs_clvfsops.c [1], where the "resvport" flag is > > > cleared > > > for NFSv4 mounts. > > > > > > Why does "reserved port logic" differ in NFSv3 and NFSv4 clients? > > > > > It is my understanding that NFSv4 servers are not supposed to > > require > > a "reserved" port#. However, at a quick glance, I can't find that > > stated > > in RFC 3530. (It may be implied by the fact that NFSv4 uses a "user" > > based > > security model and not a "host" based one.) > > > > As such, the client should never need to "waste" a reserved port# on > > a NFSv4 > > connection. > > Since AUTH_SYS can be used in NFSv4 as well and according to RFC 3530 > AUTH_SYS in NFSv4 has the same logic as in NFSv2/3, then > > 1. Does "user" based security model mean RPCSEC_GSS? > > 2. Does "host" based security model mean AUTH_SYS? > My guess is that AUTH_SYS is not considered a security model at all, but the "authenticators" refer to users. I believe the "host" based security model referred to in the RFCs refers to the restrictions implemented by /etc/exports, based on client host IP addresses. I do remember that the IETF working group discussed "reserved port #s" and agreed that requiring one did not enhance security and that NFSv4 servers should not require that a client's port# be within a certain range. (If you were to search the archive for nfsv4@ietf.org, it should be somewhere in there.) However, I agree that this does not seem to be stated in the RFCs, because I couldn't find it when the question came up. (It may be that IETF does not have a definition of a "reserved port#".) Personally, I agree with the working group and have always thought requiring a client to use a "reserved port#" was meaningless. However, I already noted that I don't mind enabling it, with a comment that it should not be required for NFSv4. > I did not find any mention about port numbers in RFC 1813 and 3530, > looks like that ports numbers range used by NFS clients and checked by > NFS server is the implementation decision. During interoperability testing (I'll be at another NFSv4 Bakeathon in June) I have never had a server that would not allow a connection to happen from a non-reserved port# for NFSv4, so I believe that the implementation practice is to not require it for NFSv4. (Consistent with the discussion on nfsv4@ietf.org.) rick