RE: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt

bhalevy@panasas.com

From: "Benny Halevy" <bhalevy@panasas.com>
Subject: RE: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt
Message-ID: <LCEAJMHHKPKEPAIDBBEKOEADCBAA.bhalevy@panasas.com>
Date: Wed, 11 Feb 2004 20:14:10 -0500

Folks, first, the draft looks much more sensible than its previous
version.

1) IMO NFSv4 "OWNER", "GROUP", and "EVERYONE" better be referred as
"OWNER@", "GROUP@", and "EVERYONE@" respectively. See rfc3530
section 5.11.6.  Mode and ACL Attribute

2) A couple of technical comments:
- NFSv4 is now rfc3530 not rfc3010.
- there are a lot of control characters in the text (backspaces?)

3) The draft could use an example.

4) It'd be great if as the next step we define how a POSIX compliant server
should support NFSv4 ACLs.  What NFSv4 ACE types and flags can be supported
and how they should be translated into the posix model.

Regards,

Benny (who's Mitch?) Halevy

> -----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