linux-kernel - Re: [PATCH 2/2] NFSv4: Return the delegation if the server returns NFS4ERR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 8 Mar 2012 15:57:37 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
Cc:	Olga Kornievskaia <aglo@...i.umich.edu>,
	Miklos Szeredi <miklos@...redi.hu>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] NFSv4: Return the delegation if the server returns
 NFS4ERR_OPENMODE

On Thu, Mar 08, 2012 at 08:50:14PM +0000, Myklebust, Trond wrote:
> On Thu, 2012-03-08 at 15:42 -0500, J. Bruce Fields wrote:
> > On Thu, Mar 08, 2012 at 03:23:34PM -0500, Olga Kornievskaia wrote:
> > > On Thu, Mar 8, 2012 at 1:15 PM, Myklebust, Trond
> > > <Trond.Myklebust@...app.com> wrote:
> > > > On Thu, 2012-03-08 at 12:52 -0500, Olga Kornievskaia wrote:
> > > >> wouldn't it be better for you to proactively return a read delegation
> > > >> then unnecessarily erroring?
> > > >
> > > > If nobody else holds a delegation, then the NFS client is actually
> > > > allowed to keep its read delegation while writing to the file. It does
> > > > admittedly need to request an OPEN stateid for write in that case...
> > > > (See section 10.4 of RFC3530bis draft 16)
> > > 
> > > If we both agree that there has to be a request for an open stateid for
> > > a write, then instead of returning the read delegation if the client receives
> > > err_openmode (when it send the request with read delegation stateid
> > > as you said per 3560bis), can't the client resend the setattr with the open
> > > stateid? The ordering of the stateid usage is a "should" and not a "must".
> > > 
> > > In rfc5661, it really doesn't make sense to ever send a setattr with
> > > a read delegation stateid. According to 9.1.2, the server "MUST" return
> > > err_open_mode" error in that case.
> > > 
> > > I gather you are in this case dealing with 4.0 delegations. But I wonder
> > > if you'll do something else for 4.1 delegation then?
> > 
> > 3530bis has the same language ("...must verify that the access mode
> > allows writing and return an NFS4ERR_OPENMODE error if it does not").
> 
> OK, so we shouldn't send the delegation stateid either for v4 or v4.1.
> However should we pre-emptively return the delegation? I've been
> assuming not.

The server's only legal option is to recall it, so it seems odd not to
pre-emptively return--but as you say there's nothing to prevent the
server from then handing one right back, possibly before you get a
chance to send the setattr.

(And the linux server might well do that--maybe it should have some
heuristic not to hand out a delegation that was just returned--not so
much for this case as just because a return is a sign that the
delegation isn't useful to that client.)

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/