Subject: [nfsv4] encouraging servers to accept all NFSv4 ACLs

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

The current spec includes this paragraph:

	The NFS version 4 ACL model is quite rich. Some server platforms
	may provide access control functionality that goes beyond the
	UNIX-style mode attribute, but which is not as rich as the NFS
	ACL model. So that users can take advantage of this more limited
	functionality, the server may indicate that it supports ACLs as
	long as it follows the guidelines for mapping between its ACL
	model and the NFS version 4 ACL model.

This may encourage implementations to restrict the subset of ACLs that
they accept in ways that limit interoperability.  We've tried this and
found that it is a problem in practice.

Would there be any objection to replacing the final sentence by the
following?:

	So that users can take advantage of this more limited
	functionality, the server may support the acl attribute by
	mapping between its ACL model and the NFS version 4 ACL model.
	Such servers SHOULD nevertheless accept any NFSv4 ACL, and
	ensure that the ACL they actually store or enforce is at least
	as strict as the NFSv4 ACL that was set.

--b.

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index d4d7650..7a34239 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -147,10 +147,12 @@
                 The NFS version 4 ACL model is quite rich. Some server
                 platforms may provide access control functionality that goes
                 beyond the UNIX-style mode attribute, but which is not as rich
-                as the NFS ACL model. So that users can take advantage of this
-                more limited functionality, the server may indicate that it
-                supports ACLs as long as it follows the guidelines for mapping
-                between its ACL model and the NFS version 4 ACL model.
+                as the NFS ACL model.  So that users can take advantage of this
+                more limited functionality, the server may support the acl
+                attribute by mapping between its ACL model and the NFS version
+                4 ACL model.  Such servers SHOULD nevertheless accept any
+                NFSv4 ACL, and ensure that the ACL they actually store or
+                enforce is at least as strict as the NFSv4 ACL that was set.
             </t>
             <t>
                 The situation is complicated by the fact that a server may

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 5 Dec 2006 18:56:28 -0500

> 	as strict as the NFSv4 ACL that was set.

Similarly, I'd like to clarify that the discussion in the "aclsupport"
section applies only to ACE types (ALLOW, DENY, AUDIT, and ALARM), and
doesn't require a server to reject ACEs because of, for example,
unsupported mask bits.

--b.

diff --git a/nfsv41_middle_fileattributes_acls.xml b/nfsv41_middle_fileattributes_acls.xml
index 7a34239..5d491b0 100755
--- a/nfsv41_middle_fileattributes_acls.xml
+++ b/nfsv41_middle_fileattributes_acls.xml
@@ -238,9 +238,9 @@
                 <t>
                     Clients should not attempt to set an ACE unless the server
                     claims support for that ACE type. If the server receives a
-                    request to set an ACE that it cannot store, it MUST reject
+                    request to set an ACE type that it cannot store, it MUST reject
                     the request with NFS4ERR_ATTRNOTSUPP. If the server
-                    receives a request to set an ACE that it can store but
+                    receives a request to set an ACE type that it can store but
                     cannot enforce, the server SHOULD reject the request with
                     NFS4ERR_ATTRNOTSUPP.
                 </t>

---

From: Sam Falkner <[email-masked]>
Date: Tue, 05 Dec 2006 20:39:40 -0700

> 	as strict as the NFSv4 ACL that was set.

I like this idea in general, but I'm still not sure whether a server  
should accept an ACL that it cannot enforce, even when erring on the  
side of "at least as strict".  An example would be an ACL that  
disallows READ_ATTRIBUTES.  In the POSIX-draft ACL file systems that  
I know of, you can always do a stat() system call and get things like  
owner, owner_group, etc.

Do we have a good story for this?  Is there rough consensus that it's  
okay to accept a deny-read-attributes ACL but allow a principle to  
read attributes?

- Sam

---

From: Sam Falkner <[email-masked]>
Date: Tue, 05 Dec 2006 20:41:00 -0700

I think these proposed text changes are good.

- Sam

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 5 Dec 2006 23:11:55 -0500

> I know of, you can always do a stat() system call and get things like  

Well, it's a dilemna: unix-like servers (even when they have some
backend NFSv4 ACL support) may not like denying permission to do stat().
But it's pretty user-unfriendly to reject legal NFSv4 ACL's when we
don't have any ability to communicate the reason for the rejection.
Imagine copying a bunch of files between two servers that both claim
"NFSv4 ACL" support and getting errors on random files with no better
explanation than "invalid acl" (or whatever you translate ATTRNOTSUPP
to).

For the current linux code I compromise by only rejecting ACLs if they
explicitly DENY the problematic bits.

> okay to accept a deny-read-attributes ACL but allow a principle to  

For bits that just don't make sense to your server at all, I'm inclined
to allow it.  I dunno.

Maybe it would help to add an enhanced aclsupport-like attribute that
also reports which bitmasks and flags the server supports.

--b.