Subject: Re: [nfsv4] ACL discussion wrapup

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 5 Dec 2006 13:15:09 -0500

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