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

From: "Halevy, Benny" <[email-masked]>
Date: Thu, 6 Oct 2005 03:23:46 -0400

J. Bruce Fields wrote:
> 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.

Why? LOOKUP returns a filehandle uniquely identifying the file based
on atomic lookup.

Based on section 8.1.4 Use of the stateid and Locking (page 72) and
Section 14.2.16. Operation 18: OPEN (page 177):

8.1.4.  Use of the stateid and Locking
   Every stateid other than the special stateid values noted in this
   section, whether returned by an OPEN-type operation (i.e., OPEN,
   OPEN_DOWNGRADE), or by a LOCK-type operation (i.e., LOCK or LOCKU),
   defines an access mode for the file (i.e., READ, WRITE, or READ-
   WRITE) as established by the original OPEN which began the stateid
   sequence, and as modified by subsequent OPENs and OPEN_DOWNGRADEs
   within that stateid sequence.  When a READ, WRITE, or SETATTR which
   specifies the size attribute, is done, the operation is subject to
   checking against the access mode to verify that the operation is
   appropriate given the OPEN with which the operation is associated.

   In the case of WRITE-type operations (i.e., WRITEs and SETATTRs which
   set size), the server must verify that the access mode allows writing
   and return an NFS4ERR_OPENMODE error if it does not.  In the case, of
   READ, the server may perform the corresponding check on the access
   mode, or it may choose to allow READ on opens for WRITE only, to
   accommodate clients whose write implementation may unavoidably do
   reads (e.g., due to buffer cache constraints). ...

14.2.16.  Operation 18: OPEN - Open a Regular File
   Note that since the NFS
   version 4 protocol does not impose any requirement that READs and
   WRITEs issued for an open file have the same credentials as the OPEN
   itself, the server still must do appropriate access checking on the
   READs and WRITEs themselves.

This tells me that I/O is restricted by share reservations and locks,
i.e. if you opened a file for read you can't issue writes (even if the
file's permissions allow you that), but the fact that you successfully
opened a file for some mode doesn't automatically grant you that access
mode. In particular, I/O may be denied based to the file's permissions
or ACL.

The bottom line in my opinion is that the client may or may not collate
opens as it does when it has a write delegation or it may not.  In the
latter case it should use different openowners for different local
accessors, for the former, all opens should be done on the same openowner.
In either case, access granted on open is not guaranteed for subsequent
I/O.

I agree that OPENing the file for each local open() will help servers
who do maintain access grants based on the open state do that but I
didn't see anything mandating that in the spec. Not on the client side
nor on the server's.

Benny

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 6 Oct 2005 11:29:44 -0400

> Why? LOOKUP returns a filehandle uniquely identifying the file based

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, 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.  There doesn't seem to be much advantage to allowing this.

--b.