{READ,WRITE}_NAMED_ATTRS (was RE: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt)

bhalevy@panasas.com

From: "Benny Halevy" <bhalevy@panasas.com>
Subject: {READ,WRITE}_NAMED_ATTRS (was RE: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt)
Message-ID: <LCEAJMHHKPKEPAIDBBEKCEAFCBAA.bhalevy@panasas.com>
Date: Wed, 11 Feb 2004 23:10:39 -0500

I've been thinking more about the READ and WRITE NAMED_ATTRS
ACE access masks and I think I have more questions than
answers at this point.

In draft-ietf-nfsv4-acl-mapping-01.txt you tie these access masks
with READ and WRITE DATA respectively. Is this the right thing to do?

How do clients use named attributes?
I guess these would be typically used to store additional information
about filesystem objects like "Description", "Title", "Author",
"Version", "Checksum", etc.  For example, I look at Microsoft's
custom file properties.  These are organized hierarchically in named
groups, each having a list of named properties having a type and
a value.  These fit pretty well into the named attributes model
but the question here is whether access control for these attributes
is tied with access to the file data?  Or should it be tied to the
access control for the file's attributes? (in posix that means
readable to everybody and writable to owner and privileged users)

Say you want to present some of the named attributes such
as "Description" or "Artist" or "Icon" when listing a directory.
You would want to be able to read their contents even when you are
not allowed to read the file's data.

Benny

> -----Original Message-----
> From: nfsv4-admin@ietf.org [mailto:nfsv4-admin@ietf.org]On Behalf Of J.
> Bruce Fields
> Sent: Wednesday, February 11, 2004 17:55
> To: nfsv4@ietf.org
> Subject: Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt
> 
> 
> On Wed, Feb 11, 2004 at 03:51:39PM -0500, Internet-Drafts@ietf.org wrote:
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-acl-mapping-01.txt
> 
> Note that anyone that cares about how to keep mode bits and acl's in
> sync also needs to pay some attention to this.
> 
> I think what we're now proposing is consistent with what's been
> discussed on this list, but speak up if anything looks wrong:
> 
> posix read bit = ACE4_READ_DATA | ACE4_READ_NAMED_ATTRS
> posix write bit = ACE4_WRITE_DATA | ACE4_WRITE_NAMED_ATTRS
> 			| ACE4_APPEND_DATA | ACE4_DELETE_CHILD
> 		(though ACE4_DELETE_CHILD actually only has meaning on
> 		 directories)
> posix execute bit = ACE4_EXECUTE_BIT | ACE4_READ_DATA
> 
> Also, everyone gets ACE4_READ_ATTRIBUTES | ACE4_READ_ACL, and the
> owner (and only the owner) gets ACE4_WRITE_ATTRIBUTES | ACE4_WRITE_ACL.
> Also (I just realized this got left out of the above draft), everyone
> should get DELETE (at least on files).
> 
> We're making some assumptions here:
> 	1. ACE4_WRITE_DATA (and ACE4_APPEND_DATA?) are sufficient to
> 	   allow someone to modify the length of a file;
> 	   ACE4_WRITE_ATTRIBUTES is not required.
> 	2. ACE4_WRITE_ATTRIBUTES does not give the right to modify mode
> 	   bits, ACLs, or named attributes
> 	3. ACE4_DELETE_CHILD on the directory is always required for
> 	   unlink to succeed; ACE4_DELETE doesn't allow this to be
> 	   bypassed.  (Mitch Halevy's interpretation that ACE4_DELETE
> 	   would only be checked when removing the last link made sense
> 	   to me.)
> 
> Arguments welcomed.--b.
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4