From owner-freebsd-fs@FreeBSD.ORG Fri Dec 9 15:29:24 2011 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 60D761065670 for ; Fri, 9 Dec 2011 15:29:24 +0000 (UTC) (envelope-from jwd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 339798FC0C; Fri, 9 Dec 2011 15:29:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pB9FTOsN047283; Fri, 9 Dec 2011 15:29:24 GMT (envelope-from jwd@freefall.freebsd.org) Received: (from jwd@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pB9FTNtN047282; Fri, 9 Dec 2011 15:29:23 GMT (envelope-from jwd) Date: Fri, 9 Dec 2011 15:29:23 +0000 From: John De To: Rick Macklem Message-ID: <20111209152923.GA47235@FreeBSD.org> References: <476FC2247D6C7843A4814ED64344560C052A32AD@seaxch10.desktop.isilon.com> <1606267322.1154407.1323390804038.JavaMail.root@erie.cs.uoguelph.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1606267322.1154407.1323390804038.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org Subject: Re: RFC: NLM patch that is more permissive w.r.t. F_RDLCK and F_UNLCK 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, 09 Dec 2011 15:29:24 -0000 Hi Rick, We have the patch installed and will start running some tests against it today. I appreciate the time you & others have invested in this patch. Thanks, John ----- Rick Macklem's Original Message ----- > I have been working on getting a patch for the NLM, originally > submitted by John De (jwd@) ready to commit to -current/head. > The original patch fixes the case where a client attempts a read > lock, but the uid on the client only has read access for the file. > (This is allowed by POSIX and local file locking, from what I can see.) > > I did make one change to his patch, which is to fall back to a test > for write access when read access doesn't exist. This is a little > weird, but since the unpatched code always checked for write access, > this ensures that it will still work if it did without the patch. > > While testing I also spotted a problem where, if file permissions are > changed between a lock and an unlock, the unlock could fail, resulting > in the file being left locked "forever". > > When discussing this off-list, Zack responded with the following, which > I have added to the patch. (ie. Being permissive w.r.t. unlock and blocking > lock cancellation, so that a lock doesn't get left "forever".) > Zack Kirsch wrote (re-posted with his permission): > > Hey Rick, Doug, > > > > I completely agree. I've already implemented this change at Isilon, > > where unlock passes a flag into nlm_get_vfs_state(). If the flag > > is 0, then it causes the following to be skipped: > > * VFS_CHECKEXP (because you still want to allow unlocking even > > though exports have changed) > > * read-only checks > > * svc_getcred (because the cred isn't needed) > > * Any cred checks > > * VOP_ACCESS call > > Does anyone see a problem with this? > (There could be a security argument against it, but I will simply note that > there is really no security against faulty clients in NFSv3 using AUTH_SYS > and, since clients normally check that an open of the appropriate type exists > in the client before attempting the locking operation against the server, > if the client is "trusted" then this shouldn't be an issue.) > > The patch is at: > http://people.freebsd.org/~rmacklem/nlmrlock.patch > > Please comment on the above or the patch. > > Thanks, rick >