Subject: [nfsv4] ACL discussion wrapup

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 8 Nov 2006 16:45:19 -0800

Hi,

   Attached is the Word doc I put together in the process
of clarifying my thinking on the attributes proposed by
Bruce.  Per the discussion today, it seems we should also
add an optional ACL4_DEFAULTED flag, to indicate that the
ACL was ginned up based on a file creator's credentials,
because the parent directory didn't have an ACL at the
time of creation.  It would indicate to a client doing auto
inheritance that it is okay to blow away the defaulted acl
and replace it with an inherited one descending from above.

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
=============================================================== 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Andreas Gruenbacher <[email-masked]>
Date: Thu, 9 Nov 2006 02:10:03 +0100

Hello,

> and replace it with an inherited one descending from above.

is there any more information available on this proposed flag? It's not clear 
to me that SE_DACL_DEFAULTED applies to file system objects at all under 
Windows; it could also be an Active Directory only thing from my reading of 
MS docs.

Do you have a particular use case in mind?

Thanks,
Andreas

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 8 Nov 2006 20:22:41 -0500

> and replace it with an inherited one descending from above.

I think the discussion of SE_DACL_AUTO_INHERITED,
SE_DACL_AUTO_INHERIT_REQ, and ACL4_AUTO_INHERIT isn't quite right.

My understanding:

	SE_DACL_AUTO_INHERITED is what ACL4_AUTO_INHERIT is meant to be
	a counterpart to.  I think the intention was to aid migration of
	filesystems to Windows 2000: on a preexisting filesystem this
	bit would be cleared, and a user could be given the opportunity
	to set it at some point when they decided to transition to the
	new behavior.  I imagine NFSv4 (and multiprotocol) servers will
	want something like that.  Hence the statement that it is
	"always set for Win2k DACLs" doesn't imply that it's useless.

	SE_DACL_AUTO_INHERIT_REQ: I don't actually know what this is.
	My impression was that it's something internal to the Windows
	API; i.e., some bit that you set in a flag argument to certain
	ACL-setting function calls, that requests that the function also
	perform any automatic inheritance required.  So I don't believe
	it has a place in the protocol.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 10 Nov 2006 17:58:40 -0500

> Windows; it could also be an Active Directory only thing from my reading of 

Just googling around....  From

http://technet2.microsoft.com/WindowsServer/en/library/9c7bc921-2517-4e7a-ba39-d37c8b8202e31033.mspx?mfr=true

it does look like DEFAULTED is set in the case above.  But the real test
would be for someone to actually experiment with a Windows system.

In NFSv4 there are two possible sources that determine the ACL on a new
object: the ACL (and/or mode) attributes sent with the OPEN or CREATE
call, and the inheritable ACLs on the parent.

In Windows there appear to be three:
	- inheritable ACLs on the parent
	- ACLs included with the create (actually with the security
	  descriptor included in the create)
	- a default ACL associated with a given "access token"; I don't
	  understand what that is, but it's apparently some
	  representation of the user.

The DEFAULTED flag is set in the third case, and only when the first two
are absent.  Since we don't this default-ACL-for-a-user notion in NFSv4,
I don't believe we can take advantage of the DEFAULTED flag.

--b.