Subject: RE: [nfsv4] automatic inheritance

From: "Yoder, Alan" <[email-masked]>
Date: Thu, 2 Nov 2006 10:57:17 -0800

Could we please change "acl_auto_inherited" to
"acl_auto_inherit"?  The flag specifies something
to do, not something that's been done.

Looks fine to me, otherwise.

Thanks,

Alan 

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]] 
> Sent: Friday, October 06, 2006 4:21 PM
> To: [email-masked]
> Subject: [nfsv4] automatic inheritance
> 
> Here's my attempt at specifying automatic inheritance.  It's 
> in the form
> of a diff against the -07 source.  I hope that's not too annoying to
> read....  Skip down to the section titled "Automatic Inheritance" for
> the meat of it.
> 
> The main requirement here is to provide protocol sufficient to support
> Windows applications using automatic inheritance, and I'll be grateful
> for review from any Windows experts.  I haven't done any 
> actual Windows
> testing, so while I believe I've gotten it right, it's still true that
> in some cases I'm guessing semantics based on incomplete 
> documentation.
> 
> The basic motivation for this feature is something like this:
> 
> You set up a directory hierarchy using inherited ACLs.  Then 
> one day you
> decide to change the inherited ACLs.  But meanwhile some files and
> subdirectories have sprouted customized ACLs of their own, which you
> don't want to lose.  Hours of perl scripts later, you're 
> still not sure
> if you've sorted out the whole mess.....
> 
> Automatic inheritance to the rescue: it doesn't automatically 
> propagate
> the changes to inherited ACLs for you[1], but it gives you some useful
> tools for doing it yourself:
> 
> 	- The new "INHERITED_ACE" flag is set on every inherited (as
> 	  opposed to inheritable) ACE, so you can sort out inherited
> 	  ACEs from ACEs that were added later.
> 
> 	- The "acl_protected" attribute marks files or subdirectories
> 	  that shouldn't receive inheritance changes.
> 
> 	- And finally an "acl_auto_inherited" attribute controls whether
> 	  to perform automatic inheritance *from* a specific directory.
> 
> The best explanation I've run across, from a 
> user/administrator's point
> of view, is here:
> http://www.pluralsight.com/wiki/default.aspx/Keith.GuideBook.W
> hatIsACLInheritance
> 
> My impression is that multiprotocol servers already support something
> like this for their CIFS clients.
> 
> So does it look like something we want?  Comments appreciated.
> 
> Thanks to Andreas Gruenbacher for comments on a couple earlier drafts.
> 
> --b.
> 
> [1] Well, actually, it does.  But the "it" here that does the 
> automatic
> propogation isn't the server, it's just some application or library on
> your client.  Think of it as a kind of fancy chmod -R.
> 
> ---
>  dotx.d/head.x                         |    5 ++
>  nfsv41_middle_fileattributes.xml      |   15 +++++-
>  nfsv41_middle_fileattributes_acls.xml |  101 
> ++++++++++++++++++++++++++++++++-
>  3 files changed, 119 insertions(+), 2 deletions(-)
> 
> diff --git a/dotx.d/head.x b/dotx.d/head.x
> index b7da386..aa3ea82 100755
> --- a/dotx.d/head.x
> +++ b/dotx.d/head.x
> @@ -266,6 +266,7 @@ const ACE4_INHERIT_ONLY_ACE		
> = 0x0000000
>  const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG	= 0x00000010;
>  const ACE4_FAILED_ACCESS_ACE_FLAG	= 0x00000020;
>  const ACE4_IDENTIFIER_GROUP		= 0x00000040;
> +const ACE4_INHERITED_ACE		= 0x00000080;
>  
>  
>  /*
> @@ -602,6 +603,8 @@ typedef layouttype4	fattr4_layout_types<
>  typedef nfs_impl_id4	fattr4_recv_impl_id;
>  typedef nfs_impl_id4	fattr4_send_impl_id;
>  typedef mdsthreshold4	fattr4_mdsthreshold;
> +typedef bool		fattr4_acl_auto_inherited;
> +typedef bool		fattr4_acl_protected;
>  
>  /*
>   * Mandatory Attributes
> @@ -679,6 +682,8 @@ const FATTR4_LAYOUT_BLKSIZE	= 65;
>  const FATTR4_LAYOUT_ALIGNMENT	= 66;
>  const FATTR4_FS_LOCATIONS_INFO	= 67;
>  const FATTR4_MDSTHRESHOLD	= 68;
> +const FATTR4_ACL_AUTO_INHERITED	= 69;
> +const FATTR4_ACL_PROTECTED	= 70;
>  
>  
>  typedef opaque	attrlist4<>;
> diff --git a/nfsv41_middle_fileattributes.xml 
> b/nfsv41_middle_fileattributes.xml
> index e62c067..afc63e0 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,
> +	      acl_auto_inherited, acl_protected
>  	    </t>
>  	  </list>
>  	</t>
> @@ -287,6 +288,18 @@
>  	The access control list for the object.
>        </c>
>  
> +      <c>acl_auto_inherited</c><c>69</c><c>bool</c><c>R/W</c>
> +      <c>
> +	If true, ACLs on this object may be dynamically inherited by
> +	child objects.
> +      </c>
> +
> +      <c>acl_protected</c><c>70</c><c>bool</c><c>R/W</c>
> +      <c>
> +	If true, ACLs on this object and its descendents should not be
> +	modified by automatic inheritance.
> +      </c>
> +
>        <c>aclsupport</c><c>13</c><c>uint32</c><c>READ</c>
>        <c>
>  	Indicates what types of ACLs are supported on the 
> current file system.
> diff --git a/nfsv41_middle_fileattributes_acls.xml 
> b/nfsv41_middle_fileattributes_acls.xml
> index 6549a7a..59ee532 100755
> --- a/nfsv41_middle_fileattributes_acls.xml
> +++ b/nfsv41_middle_fileattributes_acls.xml
> @@ -563,6 +563,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
> @@ -680,7 +681,19 @@
>                                      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.
> +				</t>
> +
>                          </list>
>                      </t>
>                  </section>
> @@ -1213,6 +1226,92 @@
>                      target="setattr" />.
>                  </t>
>              </section>
> +	    
> +            <section title="Automatic Inheritance">
> +              <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, we 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.
> +              </t>
> +              <t>
> +		The reach of this propogation may be limited in 
> two ways:
> +		first, automatic inheritance is not performed from any
> +		directory that does not have the 
> acl_auto_inherit attribute
> +		set to true; and second, automatic inheritance stops at
> +		any point in the directory tree where an object with
> +		acl_protected set to true is found, preventing 
> modification of
> +		that object's ACEs and (if it is a directory) any of its
> +		descendants.
> +              </t>
> +              <t>
> +		The ACE4_INHERITED_ACE and the two new attributes
> +		(acl_protected and acl_auto_inherit) are both 
> optional, but a
> +		server that supports one of these must support 
> all three.
> +		A client can therefore probe for automatic 
> inheritance support
> +		by checking whether the server supports the new 
> attributes.
> +              </t>
> +	      <t>
> +	        New objects should have the acl_protected 
> attribute set to
> +		false, and the acl_auto_inherit attribute set 
> to the same
> +		value as it has on the parent object.
> +	      </t>
> +              <t>
> +		To prevent clients that do not support the new
> +		ACE4_INHERITED_ACE flag from seeing it, servers 
> MUST clear any
> +		occurrences of the flag before returning any 
> ACL to the client,
> +		unless the client also requests one of the new 
> attributes
> +		(acl_protected or acl_auto_inherit) in the same GETATTR
> +		operation which requests the ACL.
> +              </t>
> +              <t>
> +		Similarly, on SETATTR, the server SHOULD set 
> the acl_protected
> +		attribute to true whenever the ACL is set 
> without the SETATTR
> +		simultaneously setting one of the new 
> attributes.  By not
> +		setting the new 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 acl_protected attribute to true. 
>  This behavior
> +		is not enforced by servers, but violations of 
> these rules 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 acl_protected 
> attribute for that
> +		file to true.
> +              </t>
> +            </section>
>          </section>
>      </section>
>  </section>
> -- 
> 1.4.2.3.gabd697
> 
> 
> _______________________________________________
> 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: "J. Bruce Fields" <[email-masked]>
Date: Thu, 2 Nov 2006 16:09:30 -0500

> Looks fine to me, otherwise.

Yeah, makes sense, thanks.--b.