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 18:15:26 +0000
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	Olga Kornievskaia <aglo@...i.umich.edu>
CC:	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, 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)

That said, in either case we do need to deal with the fact that a new
delegation may be granted after we return the old one. There is no
locking around the setattr call to prevent this.

> i also don't understand how this error occurs. doing a setattr in this
> case you must have used a non-special stateid. the server would only
> return an err_openmode if you sent the setattr with a read delegation
> stateid. i guess my question is what stateid would you use that from
> client's perspective represent a write-type state id but yet a server
> would flag as having wrong access type?

The read delegation stateid is being sent as per the prescription in
section 9.1.3.6 of RFC3530bis.

> also i'm curious why would a server, instead of returning
> err_openmode, would not first recall your read delegation?

It could, but why do so when it can just return an error value? The
presence of the delegation stateid in the SETATTR request allows it to
communicate directly to the client what the problem is without the need
for any callbacks.

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ