Subject: RE: [nfsv4] ACCESS and the SYNCHRONIZE bit

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 4 May 2006 00:27:00 -0400

Seems to me that ACCESS is useful in a multi-user client to determine if
one user should able to operate on cached state that was in fact
established by another user.

		Craig

> -----Original Message-----
> From: Peter Varga [mailto:[email-masked]] 
> Sent: Wednesday, May 03, 2006 7:44 AM
> To: 'J. Bruce Fields'; Peter Varga
> Cc: Yoder, Alan; [email-masked]; Lisa Week
> Subject: RE: [nfsv4] ACCESS and the SYNCHRONIZE bit
> 
> No, our client does not evaluate ACLs.
> 
> ACCESS is really an optimization in order to prevent the 
> client from having to "attempt" operations. Does the RFC say 
> that a client MUST send ACCESS ?
> Is it not still ultimately the server's job to check access 
> for a given user on any given operation?
> 
> CIFS/SMB need only check permissions on their 
> NT_Create_AndX_Request calls since all operations are 
> performed under a state handle. NFS needs to do it everywhere 
> since clients don't HAVE TO send ACCESS (aside from delegation).
> 
> As far as SYNCHRONIZE goes, it's meaningless over NFS. Look 
> at 5.11.2 in the
> NFSv4 RFC:
>  SYNCHRONIZE            Permission to access file locally at the
>                           server with synchronous reads and 
> writes So, NFS just needs to save this bit when 
> reading/writing ACLs, it never needs to evaluate the bit.
> 
> Peter
> 
> 
> > -----Original Message-----
> > From: J. Bruce Fields [mailto:[email-masked]]
> > Sent: Wednesday, May 03, 2006 9:47 AM
> > To: Peter Varga
> > Cc: 'Yoder, Alan'; Lisa Week; [email-masked]
> > Subject: Re: [nfsv4] ACCESS and the SYNCHRONIZE bit
> > 
> > 
> > On Fri, Apr 28, 2006 at 04:17:22PM -0400, Peter Varga wrote:
> > > The full list of the bits in an the Access Mask field of an SMB 
> > > NT_Create_AndX_Request packet (which contains the
> > functionality of ACCESS in
> > > NFS):
> > > 
> > > Generic Read
> > > Generic Write
> > > Generic Execute
> > > Generic All
> > > Maximum Allowed
> > > System Security
> > > Synchronize
> > > Write Owner
> > > Write DAC
> > > Read Control
> > > Delete
> > > Write Attributes
> > > Read Attributes
> > > Delete Child
> > > Execute
> > > Write EA
> > > Read EA
> > > Append
> > > Write
> > > Read
> > > 
> > > 
> > > I imagine this list may vary with the particular SMB dialog
> > /version, but
> > > it's not as limited as the NFSv4 ACCESS4_* bits.
> > 
> > So how are you handling the bits (like synchronize) that 
> you can't do 
> > access checks for?  Are you trying to evaluate the ACL on 
> the client 
> > side?
> > 
> > --b.
> > 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

---

From: Lisa Week <[email-masked]>
Date: Fri, 05 May 2006 14:37:33 -0600

>established by another user.
Agreed.

We've run into problems with things like the ACE4_READ_ATTRIBUTES access 
mask bit.

Suppose the ACL is set up such that one user is allowed the ability to 
READ_ATTRIBUTES and another user is denied.  If the user that is allowed 
access does an "ls -l" (or whatever) and causes the attributes to be 
cached on the client, the user that is denied the access may be able to 
read the attributes out of the client's cache.

- Lisa