Subject: Re: [nfsv4] Eliminating stateid's from pnfs IO

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 5 Oct 2005 17:48:33 -0400

On Fri, Sep 23, 2005 at 04:21:29PM -0400, Halevy, Benny wrote:
> No, as far as I know there's no guarantee for access based on open state.
> Remember that NFS OPEN is decoupled from open() syscalls on the client and
> some of them may be hidden from the server.  I/O ops may be issued with
> different credentials than the one used to open the file and therefore need
> to go through access control at I/O time.  If the client used credentials X
> to open the file and later uses credentials Y to access the file and at that
> later time access for Y is disallowed the server has no way to know that the
> file was ever successfully opened for Y as the client might had only
> verified that Y is allowed to open the file using ACCESS and not open.

Absent delegations, I believe there *does* have to be a NFS OPEN for
every open().  Since both open() and OPEN are a single atomic operation
including a lookup, there's no other way to ensure that you get the
right file.

--b.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Halevy, Benny" <[email-masked]>
Date: Thu, 6 Oct 2005 12:00:19 -0400

J. Bruce Fields wrote:
> On Thu, Oct 06, 2005 at 03:23:46AM -0400, Halevy, Benny wrote:
> > J. Bruce Fields wrote:
> > Why? LOOKUP returns a filehandle uniquely identifying the file based
> > on atomic lookup.
> 
> Maybe it could be permissable to do just a LOOKUP and ACCESS 
> in place of
> the OPEN when not doing a create, if you've already got an 
> open with the
> identical share/deny bits.  I don't think you can skip the LOOKUP,
> though, 

How does this work with the client's name cache?  What do you do
when you have a positive name cache entry for this <directory,name>
tuple and a recent getattr on the directory showed no mtime update?

> and if the LOOKUP does reveal that the path no longer maps to
> the same filehandle, then you're probably going to have to 
> send an OPEN
> anyway.  

Agreed, yet this seems to be the exception to the rule for most
applications.

> There doesn't seem to be much advantage to allowing this.

When the client gets a delegation on the file (let's assume
it's a write delegation for the purpose of this discussion),
it is supposed to cache local open() calls, right?
I assume it does use LOOKUP and ACCESS to verify the name and
permissions on the file to be opened if the share reservation
need not be changed, so this path should already exist for
clients that support delegations.  If the delegation is
recalled, do you re-OPEN the file for processes that you've cached
while having the delegation?

Benny