From owner-freebsd-fs@FreeBSD.ORG Fri May 11 12:20:23 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED8B5106564A for ; Fri, 11 May 2012 12:20:22 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 64E7C8FC0C for ; Fri, 11 May 2012 12:20:22 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SSopY-0006BP-2p; Fri, 11 May 2012 15:20:20 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id A3AF91CC34; Fri, 11 May 2012 15:20:20 +0300 (EEST) Date: Fri, 11 May 2012 15:20:20 +0300 From: Andrey Simonenko To: Rick Macklem Message-ID: <20120511122020.GA13906@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20120510130731.GA72837@pm513-1.comsys.ntu-kpi.kiev.ua> <901330725.234130.1336682055896.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <901330725.234130.1336682055896.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-05-11 15:20:20 X-Connected-IP: 10.18.52.101:52027 X-Message-Linecount: 78 X-Body-Linecount: 62 X-Message-Size: 3530 X-Body-Size: 2804 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: Fri, 11 May 2012 12:20:23 -0000 On Thu, May 10, 2012 at 04:34:15PM -0400, Rick Macklem wrote: > Andrey Simonenko wrote: > > > 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. Probably I wrongly asked the question. I did not mean that some security flavor (eg. AUTH_SYS) is a security model. I wanted to say that NFSv4 allows to use AUTH_SYS security flavor and user credentials are given as is by client's machine, so some form of control by client's IP address is required by the NFSv4 server if a client uses and is allowed to use AUTH_SYS security flavor. Actually this is specified in "16. Security Considerations" from RFC 3530 and AUTH_SYS in NFSv4 is called << "classic" model of machine authentication via IP address checking >>. What do you think about the following idea about configuration? 1. The NFS server for NFSv2/3 clients allows to specify whether their MOUNT MNT, UMNT and UMNTALL RPC requests have to or do not have to come from reserved ports. 2. The NFS server for NFSv2/3/4 clients allows to specify whether their NFS RPC calls: a) do not have to come from reserved ports b) always have to come from reserved ports c) have to come from reserved ports if clients use AUTH_SYS. 3. By default reserved ports are not required for MOUNT RPC and NFS RPC calls. Corresponding options can be used for entire file system and/or for single address specification. First item obviously is checked in a user space and second item is checked in the NFS server somewhere after VFS_CHECKEXP() when the server decides which security flavor to use. NetBSD already has -noresvmnt and -noresvport options in their exports(5). > 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. If a client machine is trusted, then reserved ports can guaranty that requests come from privileged processes and not from user space where client can fill any credentials in AUTH_SYS. If client machine is not trusted, then this will not work of course. BTW mountd requires reserved port and NFS server does not required reserved port by default.