From owner-freebsd-fs@FreeBSD.ORG Sat May 26 12:42:21 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 95AFF1065670; Sat, 26 May 2012 12:42:21 +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 12A838FC0C; Sat, 26 May 2012 12:42:20 +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 1SYGK2-0005bL-NN; Sat, 26 May 2012 15:42:18 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 811271CC34; Sat, 26 May 2012 15:42:17 +0300 (EEST) Date: Sat, 26 May 2012 15:42:16 +0300 From: Andrey Simonenko To: Rick Macklem Message-ID: <20120526124216.GA1302@pm513-1.comsys.ntu-kpi.kiev.ua> References: <20120524114702.GA38087@pm513-1.comsys.ntu-kpi.kiev.ua> <169170676.853090.1337953018295.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <169170676.853090.1337953018295.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-26 15:42:18 X-Connected-IP: 10.18.52.101:21679 X-Message-Linecount: 66 X-Body-Linecount: 50 X-Message-Size: 3371 X-Body-Size: 2588 Cc: freebsd-fs@freebsd.org, dfr Subject: Re: NLM uses AUTH_SYS ignoring sec option in mount_nfs 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: Sat, 26 May 2012 12:42:21 -0000 On Fri, May 25, 2012 at 09:36:58AM -0400, Rick Macklem wrote: > Andrey Simonenko wrote: > > Hello, > > > > Looks like that NLM always uses AUTH_SYS even if a client specified > > another security flavor in the mount_nfs's "sec" option. Also NLM > > on the server does not verify that NLM client's security flavor > > is allowed by NFS exported file system, security flavors array from > > VFS_CHECKEXP() is ignored in nlm/nlm_prot_impl.c:nlm_get_vfs_state(). > > > > Such behaviour of NLM I see on 10-CURRENT, I added log messages to > > the kernel to see security flavors used by NFSv3 and NLM requests. > > Both NFS client and server are on the same system, NFSv3 mounts are > > from unprivileged users. > > > > According to [1] NLMv4 allows to use different security flavors. > > > > Can somebody comment such behaviour of NLM? > > > Well, as you might know, I wasn't the author of the NLM implementation, > so I'm just commenting based on what little I know about it. (I've > added dfr@ to the cc list, in case he can provide more insight?) > > I think the big problem with using Kerberos with the NLM is > "what happens when the user's TGT ticket expires on the client?". > If this happens and the server requires a valid credential based > on a Kerberos ticket, then the client/user won't be able to unlock > the locks that have been put on the file. It is conceivable > that these file locks could hang around "forever". > (An obvious case here is where the user for a uid isn't actually > prsent to do a fresh kinit when the TGT expires. Another is an > application program that doesn't handle a EACCES error from a > lock syscall well.) I think this problem could be avoided by > allowing AUTH_SYS for unlock operations, so that the unlocking > won't fail. > Also, from a glance at the code, it appears that the client will > re-acquire locks after a server crashes/reboots. What do you do > if this re-acquisition fails, due to a TGT timeout? If such approach is used, then NLM will work only in cases when user credentials on a client system correspond to user credentials on a server system. When a user kinit'ed, then corresponding user's credentials are setup by the server for all NFS RPC requests. When a user opened a file, then is trying to lock it, user's credentials are passed in RPC request (because of AUTH_SYS in NLM) and a server will use them to verify whether a user is allowed to access a file that is being locked. Simple check when local credentials do not correspond to remote user credentials mapping shows that fcntl(F_SETLK) returns EACCES.