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

From: Peter Varga <[email-masked]>
Date: Fri, 28 Apr 2006 16:17:22 -0400

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.

Peter

> -----Original Message-----
> From: Yoder, Alan [mailto:[email-masked]] 
> Sent: Friday, April 28, 2006 3:25 PM
> To: Lisa Week; J. Bruce Fields
> Cc: [email-masked]
> Subject: RE: [nfsv4] ACCESS and the SYNCHRONIZE bit
> 
> 
> > Yes, this is something that we've noticed as well.  The 
> problem goes 
> > beyond the SYNCHRONIZE bit.
> > 
> > The ACCESS operation only defines the following bits:
> > 
> > const ACCESS4_READ      = 0x00000001;
> > const ACCESS4_LOOKUP    = 0x00000002;
> > const ACCESS4_MODIFY    = 0x00000004;
> > const ACCESS4_EXTEND    = 0x00000008;
> > const ACCESS4_DELETE    = 0x00000010;
> > const ACCESS4_EXECUTE   = 0x00000020;
> > 
> > 
> > As I am sure you are aware, this only covers a portion of the 
> > accesses 
> > defined by ACLs.  Which are:
> > 
> > const ACE4_READ_DATA            = 0x00000001;
> > const ACE4_LIST_DIRECTORY       = 0x00000001;
> > const ACE4_WRITE_DATA           = 0x00000002;
> > const ACE4_ADD_FILE             = 0x00000002;
> > const ACE4_APPEND_DATA          = 0x00000004;
> > const ACE4_ADD_SUBDIRECTORY     = 0x00000004;
> > const ACE4_READ_NAMED_ATTRS     = 0x00000008;
> > const ACE4_WRITE_NAMED_ATTRS    = 0x00000010;
> > const ACE4_EXECUTE              = 0x00000020;
> > const ACE4_DELETE_CHILD         = 0x00000040;
> > const ACE4_READ_ATTRIBUTES      = 0x00000080;
> > const ACE4_WRITE_ATTRIBUTES     = 0x00000100;
> > const ACE4_DELETE               = 0x00010000;
> > const ACE4_READ_ACL             = 0x00020000;
> > const ACE4_WRITE_ACL            = 0x00040000;
> > const ACE4_WRITE_OWNER          = 0x00080000;
> > const ACE4_SYNCHRONIZE          = 0x00100000;
> > 
> 
> The attributes in the shorter list are actually 
> equivalent to sums of attributes from the longer one,
> in NTFS.  I think Carl had concluded that the short 
> list attributes are the only ones that ever show up 
> on the wire in CIFS.
> 
> Alan
> 
> ===============================================================
> Alan G. Yoder                                    [email-masked]
> Technical Staff                           
> Network Appliance, Inc.                            408-822-6919
> ===============================================================
> 
> 
> 
> > -----Original Message-----
> > From: Lisa Week [mailto:[email-masked]] 
> > Sent: Friday, April 28, 2006 12:09 PM
> > To: J. Bruce Fields
> > Cc: [email-masked]
> > Subject: Re: [nfsv4] ACCESS and the SYNCHRONIZE bit
> > 
> > Hi Bruce,
> > 
> > Sorry if my responses seem a little disjoint.  I am trying to 
> > respond to 
> > each of your emails.  At the end, perhaps it would be useful to 
> > summarize the things that we have talked about in each of the 
> > different 
> > threads...
> > 
> > We should also add issues to the tracker where appropriate.
> > 
> > J. Bruce Fields wrote:
> > 
> > >Just a random question that some Windows person may be able 
> > to answer:
> > >
> > >As far as I can tell, the SYNCHRONIZE bit is something that is
> > >enforced purely by the client---whatever operations it 
> disallows are
> > >client-side operations, so the server never gets a chance to refuse
> > >them.
> > >
> > >That being the case, how does a client determine whether a 
> given user
> > >has SYNCHRONIZE rights to a given file?  The ACCESS 
> operation doesn't
> > >provide a SYNCHRONIZE bit, and clients aren't supposed to 
> attempt to
> > >evalute ACLs on their own.
> > >  
> > >
> > 
> > Yes, this is something that we've noticed as well.  The 
> problem goes 
> > beyond the SYNCHRONIZE bit.
> > 
> > The ACCESS operation only defines the following bits:
> > 
> > const ACCESS4_READ      = 0x00000001;
> > const ACCESS4_LOOKUP    = 0x00000002;
> > const ACCESS4_MODIFY    = 0x00000004;
> > const ACCESS4_EXTEND    = 0x00000008;
> > const ACCESS4_DELETE    = 0x00000010;
> > const ACCESS4_EXECUTE   = 0x00000020;
> > 
> > 
> > As I am sure you are aware, this only covers a portion of the 
> > accesses 
> > defined by ACLs.  Which are:
> > 
> > const ACE4_READ_DATA            = 0x00000001;
> > const ACE4_LIST_DIRECTORY       = 0x00000001;
> > const ACE4_WRITE_DATA           = 0x00000002;
> > const ACE4_ADD_FILE             = 0x00000002;
> > const ACE4_APPEND_DATA          = 0x00000004;
> > const ACE4_ADD_SUBDIRECTORY     = 0x00000004;
> > const ACE4_READ_NAMED_ATTRS     = 0x00000008;
> > const ACE4_WRITE_NAMED_ATTRS    = 0x00000010;
> > const ACE4_EXECUTE              = 0x00000020;
> > const ACE4_DELETE_CHILD         = 0x00000040;
> > const ACE4_READ_ATTRIBUTES      = 0x00000080;
> > const ACE4_WRITE_ATTRIBUTES     = 0x00000100;
> > const ACE4_DELETE               = 0x00010000;
> > const ACE4_READ_ACL             = 0x00020000;
> > const ACE4_WRITE_ACL            = 0x00040000;
> > const ACE4_WRITE_OWNER          = 0x00080000;
> > const ACE4_SYNCHRONIZE          = 0x00100000;
> > 
> > 
> > One way to address this would be to:
> > 1.) evaluate where there is overlap between the two set of 
> > access mask 
> > bits (those for ACCESS and those for ACLs),
> > 2.) determine what is missing and
> > 3.) add the appropriate bits to the ACCESS operation.
> > 
> >  From reading the Minor Versioning rules (section 18 of 
> minor version 
> > doc -02), this seems like a valid thing to do.  Please let 
> me know if 
> > this is a wrong conclusion.
> > 
> > Comments?
> > 
> > Thanks,
> > Lisa
> > 
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> > 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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