Subject: RE: [nfsv4] ACL discussion wrapup

From: "Yoder, Alan" <[email-masked]>
Date: Tue, 5 Dec 2006 10:26:37 -0800

I may not understand the RETENTION_HOLD attribute
correctly.  Is this a single bit?  

I'm unsure whether we want to deal with this, but a 
Microsoft architect assured me that Bill Gate's mail 
has about 100 retention holds on it.  The XAM TWG in
SNIA has a 128-bit field reserved for retention 
holds, IIRC.

Thanks,

Alan

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 10:15 AM
> To: [email-masked]
> Cc: Khan, Saadia; Andreas Gruenbacher; Yoder, Alan
> Subject: Re: [nfsv4] ACL discussion wrapup
> 
> On Mon, Nov 13, 2006 at 12:06:03PM -0500, J. Bruce Fields wrote:
> > OK.  I'll wait for any more feedback, then try to put out an updated
> > version of the proposed automatic inheritance language next 
> week, with
> > the addition of this flag.
> 
> It took me longer than expected to get around to 
> this--apologies!  This
> version adds the DEFAULTED flags and corrects some minor 
> mispellings and
> such.
> 
> I think I've incorporated all comments received up to now.  The result
> is a little larger than we had hoped, though I think the additions are
> necessary.  I believe it's still fairly straightforward, and not too
> difficult to understand or to implement (at least at the level of the
> protocol; implementing ACL editors that perform automatic inheritance
> may be more difficult.)
> 
> But it's up to the working group whether the additional complexity is
> worth it....
> 
> --b.
> 
>  dotx.d/head.x                         |   25 +++++
>  nfsv41_middle_fileattributes.xml      |   15 +++
>  nfsv41_middle_fileattributes_acls.xml |  149 
> +++++++++++++++++++++++++++++++++-
>  3 files changed, 187 insertions(+), 2 deletions(-)
> 
> diff --git a/dotx.d/head.x b/dotx.d/head.x
> index 064a774..ce4f4d2 100755
> --- a/dotx.d/head.x
> +++ b/dotx.d/head.x
> @@ -266,6 +266,7 @@ const ACE4_INHERIT_ONLY_ACE		
> = 0x00000008;
>  const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG	= 0x00000010;
>  const ACE4_FAILED_ACCESS_ACE_FLAG	= 0x00000020;
>  const ACE4_IDENTIFIER_GROUP		= 0x00000040;
> +const ACE4_INHERITED_ACE		= 0x00000080;
>  
>  
>  /*
> @@ -340,6 +341,26 @@ struct nfsace4 {
>  };
>  
>  /*
> + * ACL flag
> + */
> +typedef uint32_t aclflag4;
> +
> +/*
> + * ACL flag values
> + */
> +const ACL4_AUTO_INHERIT		= 0x00000001;
> +const ACL4_PROTECTED		= 0x00000002;
> +const ACL4_DEFAULTED		= 0x00000004;
> +
> +/*
> + * Version 4.1 Access Control List definition
> + */
> +struct nfsacl41 {
> +	aclflag4	flag;
> +	nfsace4<>	aces;
> +};
> +
> +/*
>   * Field definitions for the fattr4_mode attribute
>   */
>  const MODE4_SUID = 0x800;  /* set user id on execution */
> @@ -619,6 +640,8 @@ typedef retention_set4	fattr4_retention_set;
>  typedef retention_get4	fattr4_retentevt_get;
>  typedef retention_set4	fattr4_retentevt_set;
>  typedef uint64_t	fattr4_retention_hold;
> +typedef nfsacl41	fattr4_dacl;
> +typedef nfsacl41	fattr4_sacl;
>  
>  /*
>   * Mandatory Attributes
> @@ -701,6 +724,8 @@ const FATTR4_RETENTION_SET	= 70;
>  const FATTR4_RETENTEVT_GET	= 71;
>  const FATTR4_RETENTEVT_SET	= 72;
>  const FATTR4_RETENTION_HOLD	= 73;
> +const FATTR4_DACL		= 74;
> +const FATTR4_SACL		= 75;
>  
>  typedef opaque	attrlist4<>;
>  
> diff --git a/nfsv41_middle_fileattributes.xml 
> b/nfsv41_middle_fileattributes.xml
> index c157784..4c0b5a3 100755
> --- a/nfsv41_middle_fileattributes.xml
> +++ b/nfsv41_middle_fileattributes.xml
> @@ -175,7 +175,8 @@
>  	      space_used, system, time_access, time_backup,
>  	      time_create, time_metadata, time_modify,
>  	      mounted_on_fileid,
> -	      layout_type, layout_hint, layout_blksize, layout_alignment
> +	      layout_type, layout_hint, layout_blksize, 
> layout_alignment,
> +	      dacl, sacl
>  	    </t>
>  	  </list>
>  	</t>
> @@ -324,6 +325,12 @@
>  	Ownership" privilege).
>        </c>
>  
> +      <c>dacl</c><c>74</c><c>nfsacl41&lt;></c><c>R/W</c>
> +      <c>
> +        Automatically inheritable access control list used
> +	for determining access to filesystem objects.
> +      </c>
> +
>        <c>dir_notif_delay</c><c>56</c><c>nfstime4</c><c>READ</c>
>        <c>
>  	notification delays on directory attributes
> @@ -552,6 +559,12 @@
>          on the file object. SETATTR use only.
>        </c>
>  
> +      <c>sacl</c><c>75</c><c>nfsacl41&lt;></c><c>R/W</c>
> +      <c>
> +        Automatically inheritable access control list used
> +        for logging access to files.
> +      </c>
> +
>        <c>send_impl_id</c><c>58</c><c>impl_ident4</c><c>WRITE</c>
>        <c>
>  	Client provides server with its implementation identity 
> via SETATTR.
> diff --git a/nfsv41_middle_fileattributes_acls.xml 
> b/nfsv41_middle_fileattributes_acls.xml
> index 318b8aa..d4d7650 100755
> --- a/nfsv41_middle_fileattributes_acls.xml
> +++ b/nfsv41_middle_fileattributes_acls.xml
> @@ -582,6 +582,7 @@
>             const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG   = 0x00000010;
>             const ACE4_FAILED_ACCESS_ACE_FLAG       = 0x00000020;
>             const ACE4_IDENTIFIER_GROUP             = 0x00000040;
> +	   const ACE4_INHERITED_ACE                = 0x00000080;
>                          </artwork>
>                      </figure>
>                          A server need not support any of 
> these flags. If the
> @@ -699,7 +700,22 @@
>                                      who value equal to one 
> of the special
>                                      identifiers outlined in
>                                      <xref target="acewho" />.
> -                            </t>
> +				</t>
> +
> +                                <t hangText="ACE4_INHERITED_ACE">
> +				    <vspace />
> +                                    Indicates that this ACE 
> is inherited from
> +				    a parent directory.  A 
> server that supports
> +				    automatic inheritance will place
> +				    this flag on any ACEs 
> inherited from the
> +                                    parent directory when 
> creating a new
> +				    object.  Client 
> applications will use this
> +				    to perform automatic inheritance.
> +				    Clients and servers MUST clear this
> +				    bit in the acl attribute; 
> it may only
> +				    be used in the dacl and 
> sacl attributes.
> +				</t>
> +
>                          </list>
>                      </t>
>                  </section>
> @@ -1232,6 +1248,137 @@
>                      target="setattr" />.
>                  </t>
>              </section>
> +	    
> +            <section title="Automatic Inheritance">
> +	      <t>In addition to (or instead of) the acl 
> attribute described
> +	        above, a server may choose to support the dacl and sacl
> +		attributes.  These two attributes are identical 
> to the acl
> +		attribute, except that only ALLOW and DENY aces 
> are permitted
> +		in the dacl attribute, and only AUDIT and ALARM aces are
> +		permitted in the sacl attribute.  Also, the 
> sacl and dacl
> +		attributes both have an additional flag field 
> which applies to
> +		the entire sacl or dacl; three flag values are defined
> +                    <figure>
> +                        <artwork>
> +	   const ACL4_AUTO_INHERIT                 = 0x00000001;
> +	   const ACL4_PROTECTED                    = 0x00000002;
> +	   const ACL4_DEFAULTED			   = 0x00000004;
> +                        </artwork>
> +                    </figure>
> +		and all other bits must be cleared.  Finally, the
> +		ACE4_INHERITED_ACE flag may be set in the ACEs 
> of the sacl
> +		or dacl (whereas it must always be cleared in the acl).
> +	      </t>
> +	      <t>
> +	        Together these features allow a server to 
> support automatic
> +		inheritance, which we now explain in more detail.
> +	      </t>
> +              <t>
> +		Inheritable ACEs are normally inherited by 
> child objects only
> +		at the time that the child objects are created; later
> +		modifications to inheritable ACEs do not result in
> +		modifications to inherited ACEs on descendents.
> +              </t>
> +              <t>
> +		However, the dacl and sacl provide an optional mechanism
> +		which allows a client application to propagate 
> changes to
> +		inheritable ACEs to an entire directory hierarchy.
> +              </t>
> +              <t>
> +	        A server that supports this performs 
> inheritance at object
> +		creation time in the normal way, but also sets the
> +		ACE4_INHERITED_ACE flag on any inherited ACEs 
> as they are
> +		added to the new object.
> +              </t>
> +              <t>
> +		A client application such as an ACL editor may 
> then propagate
> +		changes to inheritable ACEs on a directory by 
> recursively
> +		traversing that directory's descendants and 
> modifying each ACL
> +		encountered to remove any ACEs with the 
> ACE4_INHERITED_ACE flag
> +		and to replace them by the new inheritable ACEs 
> (also with the
> +		ACE4_INHERITED_ACE flag set).  It uses the existing ACE
> +		inheritance flags in the obvious way to decide 
> which ACEs to
> +		propagate.  (Note that it may encounter further 
> inheritable
> +		ACEs when descending the directory heirarchy, 
> and that those
> +		will also need to be taken into account when propagating
> +		inheritable ACEs to further descendants.)
> +              </t>
> +              <t>
> +		The reach of this propagation may be limited in 
> two ways:
> +		first, automatic inheritance is not performed from any
> +		directory ACL that has the ACL4_AUTO_INHERIT flag
> +		cleared; and second, automatic inheritance 
> stops wherever
> +		an ACL with the ACL4_PROTECTED flag is set, preventing
> +		modification of that ACL and also (if the ACL is set on
> +		a directory) of the ACL on any of the object's 
> descendants.
> +              </t>
> +	      <t>
> +	        This propagation is performed independently for the sacl
> +		and the dacl attributes; thus the ACL4_AUTO_INHERIT and
> +		ACL4_PROTECTED flags may be independently set 
> for the sacl
> +		and the dacl, and propagation of one type of 
> acl may continue
> +		down a heirarchy even where propagation of the 
> other acl has
> +		stopped.
> +	      </t>
> +	      <t>
> +	        New objects should be created with a dacl and a 
> sacl that
> +		both have the ACL4_PROTECTED flag cleared and the
> +		ACL4_AUTO_INHERIT flag set to the same value as that on,
> +		respectively, the sacl or dacl of the parent object.
> +	      </t>
> +	      <t>
> +	        Both the dacl and sacl attributes are optional, 
> and a server
> +		may support one without supporting the other.
> +	      </t>
> +              <t>
> +	        A server that supports both the old acl attribute and
> +		one or both of the new dacl or sacl attributes 
> must do so
> +		in such a way as to keep all three attributes consistent
> +		with each other.  Thus the ACEs reported in the 
> acl attribute
> +		should be the union of the ACEs reported in the dacl and
> +		sacl attributes, except that the 
> ACE4_INHERITED_ACE flag must
> +		be cleared from the ACEs in the acl.  And of course a
> +		client that queries only the acl will be unable 
> to determine
> +		the values of the sacl or dacl flag fields.
> +              </t>
> +              <t>
> +	        When a client performs a SETATTR for the acl attribute,
> +		the server SHOULD set the ACL4_PROTECTED flag to true on
> +		both the sacl and the dacl.  By using the acl attribute,
> +		as opposed to the dacl or sacl attributes, the 
> client signals
> +		that it may not understand automatic 
> inheritance, and thus
> +		cannot be trusted to set an ACL for which automatic
> +		inheritance would make sense.
> +              </t>
> +              <t>
> +		When a client application queries an ACL, 
> modifies it, and sets
> +		it again, it should leave any ACEs marked with
> +		ACE4_INHERITED_ACE unchanged, in their original 
> order, at the
> +		end of the ACL.  If the application is unable 
> to do this, it
> +		should set the ACL4_PROTECTED flag.  This behavior
> +		is not enforced by servers, but violations of 
> this rule may
> +		lead to unexpected results when applications 
> perform automatic
> +		inheritance.
> +              </t>
> +              <t>
> +		If a server also supports the mode attribute, 
> it SHOULD set the
> +		mode in such a way that leaves inherited ACEs 
> unchanged, in
> +		their original order, at the end of the ACL.  
> If it is unable
> +		to do so, it SHOULD set the ACL4_PROTECTED flag 
> on the file's
> +		dacl.
> +              </t>
> +	      <t>Finally, in the case where the request that 
> creates a new file
> +	        or directory does not also set permissions for 
> that file or
> +	        directory, and there are also no ACEs to 
> inherit from the
> +		parent's directory, then the server's choice of 
> ACL for the new
> +		object is implementation-dependent.  In this 
> case, the server
> +		SHOULD set the ACL4_DEFAULTED flag on the ACL 
> it chooses for
> +		the new object.  An application performing automatic
> +		inheritance takes the ACL4_DEFAULTED flag as a 
> sign that the
> +		ACL should be completely replaced by one 
> generated using the
> +		automatic inheritance rules.
> +	      </t>
> +            </section>
>          </section>
>      </section>
>  </section>
> 

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

---

From: Mike Eisler <[email-masked]>
Date: Tue, 5 Dec 2006 10:33:00 -0800 (PST)

> correctly.  Is this a single bit?  

I didn't see where Bruce changed RETENTION_HOLD. Anyway,
it is 64 bits long, allowing up to 64 administrative
holds.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 5 Dec 2006 14:19:20 -0500

On Tue, Dec 05, 2006 at 10:33:00AM -0800, Mike Eisler wrote:
> I didn't see where Bruce changed RETENTION_HOLD.

I didn't--he probably just noticed it in the diff context.

By the way, on the new ACE4_WRITE_RETENTION and
ACE4_WRITE_RETENTION_HOLD mask bits: is a 4.1 server required to support
them?  (Can a server return NFS4ERR_ATTRNOTSUPP to a setattr that
attempts to set an ACL using with one of these bits set?)

Do comparable bits exist in Windows ACLs?

Will a 4.0 request for an ACL with one of these bits set see the bits,
or will they be cleared first?

--b.

---

From: [email-masked]
Date: Tue, 5 Dec 2006 14:26:18 -0500

I am not sure whether Windows has these bits, and I don't understand
what problem are we trying to solve with these bits.

Mario

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Tuesday, December 05, 2006 14:19
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] ACL discussion wrapup

--b.

---

From: Mike Eisler <[email-masked]>
Date: Tue, 5 Dec 2006 13:37:07 -0800 (PST)

> them?  (Can a server return NFS4ERR_ATTRNOTSUPP to a setattr that

No a v4.1 server is not required to support them.

> attempts to set an ACL using with one of these bits set?)

If an NFSv4.1 implementation supports retention
and ACLs it had better support ACE4_*RETENTION*. Otherwise
the interop matrix gets too complex.

In the server's inode, if it doesn't  have separate
permission bits for retention, then the ACE*RETENTION* bits
can be mapped to something else. 

> Do comparable bits exist in Windows ACLs?

I doubt it.

> or will they be cleared first?

An NFSv4.0 request to SETATTR an ACL with those bits is in error.
Similarly, and NFSv4.0 response with those bits is in error.

---

From: Mike Eisler <[email-masked]>
Date: Tue, 5 Dec 2006 13:41:02 -0800 (PST)

> what problem are we trying to solve with these bits.

Last summer, I proposed a very modest set of changes, but
feedback from SNIA was that we needed something more complex,
hence the current state of Retention. If the consensus is that
we need something simpler, that's fine with me. Someone make a
proposal.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 5 Dec 2006 17:12:39 -0500

> No a v4.1 server is not required to support them.

This contributes somewhat to a problem we already have, which is that
the ACL is a complex multipart attribute which can be rejected by a
server for a variety of reasons, and that the only errors available to
the server to communicate the reason for the rejection are BADOWNER and
ATTRNOTSUPP.  This leaves a user without much guidance as to how to fix
the problem.

The client could discover the reason for the rejection in this case by
querying support for the other retention attributes and then returning
an error.  It's not something a client implementator not interested in
retention support would probably think to do, though....

Or we could advise servers without support to just silently ignore those
bits.

Maybe a finer-grained aclsupport attribute would also help?

> the interop matrix gets too complex.

Makes sense.  Could we add language which makes this explicit?

> Similarly, and NFSv4.0 response with those bits is in error.

So the server has a choice between returning an error on such a GETATTR
or returning an ACL with the new bits cleared.

If it does the latter, should it try to do anything special to avoid the
obvious loss of information on a read-modify-write over NFSv4.0?

--b.