Date: Thu, 10 May 2012 16:34:15 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions Message-ID: <901330725.234130.1336682055896.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120510130731.GA72837@pm513-1.comsys.ntu-kpi.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?901330725.234130.1336682055896.JavaMail.root>