Subject: [nfsv4] automatic inheritance

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 6 Oct 2006 19:21:16 -0400

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

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 6 Oct 2006 19:30:44 -0400

> read....  Skip down to the section titled "Automatic Inheritance" for

By the way, one known issue: Mike Eisler pointed out one subtle
difference between NFSv4 and NT ACLs during the last conference call,
which is that Windows separates the "DACL" (ALLOW and DENY ACEs) from
the "SACL" (AUDIT and ALARM ACEs), whereas we lump them all together in
one object.

There's some concern this could cause problems, for example if a client
that doesn't understand AUDIT and ALARM ACEs discards them when it
modifies the ACL.

This also affects automatic inheritance, which in Windows can be
controlled separately for DACLs and SACLs; for example, automatic
inheritance might be turned on for one but not the other.  I've ignored
this problem for now....

--b.