From owner-freebsd-fs@FreeBSD.ORG Sat Dec 10 00:00:57 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 CE5F0106564A; Sat, 10 Dec 2011 00:00:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 749BD8FC0C; Sat, 10 Dec 2011 00:00:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAKmf4k6DaFvO/2dsb2JhbAA7CBaEcKZ6gXIBAQQBI1YFFg4KAgINGQJZBogaCKQvkSiBNIcIgiCBFgSIMIxAiReJLg X-IronPort-AV: E=Sophos;i="4.71,329,1320642000"; d="scan'208";a="149742549" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 09 Dec 2011 19:00:56 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 69EF8B4045; Fri, 9 Dec 2011 19:00:56 -0500 (EST) Date: Fri, 9 Dec 2011 19:00:56 -0500 (EST) From: Rick Macklem To: John De Message-ID: <1926966674.1448.1323475256413.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20111209152923.GA47235@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) 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: Sat, 10 Dec 2011 00:00:57 -0000 John De wrote: > 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. > Don't thank me. You did all the real work on this. I'm just stickhandling it into head...rick > 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 > >