Subject: [nfsv4] Automatic inheritance of permissions

From: Andreas Gruenbacher <[email-masked]>
Date: Tue, 20 Jun 2006 20:55:07 +0200

I would like to propose to add a dynamic permission inheritance scheme to the 
NFSv4 specification similar to Windows's automatic inheritance: as far as I 
can tell, the NFSv4 ACL model is based on the Windows NT ACL model. This 
model was revised in Windows 2000; yet NFSv4 still only specifies NT-style 
ACLs. I think this will lead to poor interoperability with Windows and harder 
to use ACLs, and so we should try to improve the NFSv4 specs to avoid that.

Let me try to describe the differences between the Windows NT and Windows 2000 
models.

Setting up Windows permissions for an individual file or directory isn't 
exactly trivial, but setting up and modifying permissions for an entire 
directory tree used to be awful: up to Windows 2000, without special tools, 
the only way permissions could be applied to an entire directory tree was to 
apply them to every file and directory, recursively. Any detailed permissions 
set on individual files or directories anywhere in the directory tree were 
wiped out in the process.

With automatic inheritance in Windows 2000, permissions propagate to child 
objects when children are created as before, but inherited ACL entries (ACEs) 
additionally have the INHERITED_ACE flag set. Additional ACEs which won't 
have this flag set can be defined for child objects without confusing 
inherited and individual permissions. ACLs of objects can also have the 
SE_DACL_PROTECTED flag set, which means that permissions from objects higher 
up in the tree will not inherit into them.

When inheritable permissions of a container object are modified, these 
permissions propagate down the entire tree of child objects, updating the 
inherited permissions, while leaving the individual permissions intact. There 
are ordering rules among inherited and individual permissions so that the 
resulting permissions are well defined.

Automatic inheritance reduces the complexity of ACLs in a directory tree a 
lot: with this scheme, you only have to look at those places in the directory 
tree where additional 

When changing permissions, the client are responsible for walking sub-trees 
and recomputing inherited permissions, so when a client dies or gets 
disconnected, objects may end up with inconsistent permissions. The 
inheritance mechanism is idempotent though, so an interrupted permission 
inheritance operation can be restarted, resulting in consistent, correct 
permissions in the end.

Any thoughts?

Thanks,
Andreas

-- 
Andreas Gruenbacher <[email-masked]>
Novell / SUSE Labs

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 20 Jun 2006 16:55:16 -0400

> resulting permissions are well defined.

Where can we find the details on all of this?

> lot: with this scheme, you only have to look at those places in the directory 

Sorry?

> inheritance operation can be restarted, resulting in consistent, correct 

Are clients required or expected to do this?  Or is it up to your ACL editor?

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 21 Jun 2006 14:16:45 -0500

> Are clients required or expected to do this?  Or is it up to your ACL editor?

My understanding is (and we have had this thread of discussion before)
that the application is responsible for the automatic/propagation of
ACLs.

Spencer

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 21 Jun 2006 15:33:59 -0400

> that the application is responsible for the automatic/propagation of

Yeah, definitely.  I just wanted to make sure Andreas wasn't proposing
something more involved.

So the INHERITED_ACE just becomes a hint for an application that recursively
propagates new inherited ACLs, identifying which old ACEs the application
should remove?

I guess that seems straightforward enough to me.

And if I understand right, the SE_DACL_PROTECTED bit applies to an entire ACL,
not to a single ACE, so it'd need to be a separate attribute on the file, not a
new ACE mode bit or flag?

And the SE_DACL_PROTECTED bit is also just a hint to the application
propagating ACLs, not something that the server can (or should) enforce?

--b.

---

From: Andreas Gruenbacher <[email-masked]>
Date: Thu, 22 Jun 2006 12:46:23 +0200

> Yeah, definitely.  I just wanted to make sure Andreas wasn't proposing

Yes, changing the ACLs of existing files would be a client-side 
responsibility.

> So the INHERITED_ACE just becomes a hint for an application that
> recursively propagates new inherited ACLs, identifying which old ACEs the
> application should remove?

In parts, yes. The server must still propagate the INHERITED_ACE flags 
properly when creating objects though. It must also implement the same ACE 
ordering semantics.

> And if I understand right, the SE_DACL_PROTECTED bit applies to an entire
> ACL, not to a single ACE, so it'd need to be a separate attribute on the
> file, not a new ACE mode bit or flag?

The protected flag is per ACL, yes.

> propagating ACLs, not something that the server can (or should) enforce?

That's how I understand it, yes.

Andreas

---

From: Andreas Gruenbacher <[email-masked]>
Date: Thu, 22 Jun 2006 14:20:10 +0200

On Tuesday, 20 June 2006 22:55, J. Bruce Fields wrote:
> > inherited permissions, while leaving the individual permissions intact.
> > There are ordering rules among inherited and individual permissions so
> > that the resulting permissions are well defined.
>

There's a lot of information about this on MSDN:

http://msdn.microsoft.com/library/en-us/secauthz/security/ace_header.asp

	Type ACE_HEADER and the INHERITED_ACE flag.

http://msdn.microsoft.com/library/en-us/secauthz/security/security_descriptor_control.asp

	Type SECURITY_DESCRIPTOR_CONTROL and the
	SE_DACL_PROTECTED flag.

http://msdn.microsoft.com/library/en-us/secauthz/security/automatic_propagation_of_inheritable_aces.asp

	"Directly applied ACEs have precedence over inherited ACEs. The system
 	implements this precedence by placing directly applied ACEs ahead of
	inherited ACEs in a discretionary access control list (DACL)."

http://msdn.microsoft.com/library/en-us/secauthz/security/order_of_aces_in_a_dacl.asp

	Details the algorithm for (re)computing the inherited entries of an ACL.

> > Automatic inheritance reduces the complexity of ACLs in a directory tree
> > a lot: with this scheme, you only have to look at those places in the
> > directory tree where additional
>
> Sorry?

Let me try again.

Automatic inheritance reduces the complexity of ACLs in a directory tree a 
lot: with this scheme, you only have to look at those places in the directory 
tree where additional ACEs are introduced. The inherited ACEs will have the 
same effect across the entire sub-directory tree, so they only need to be 
understood once. ACL editors can present inherited ACEs differently from 
explicit ACEs. Without automatic inheritance, it is much more difficult to 
spot the relevant changes.

Andreas

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 22 Jun 2006 09:23:46 -0400

> There's a lot of information about this on MSDN:

Great, thanks for the pointers.--b.

---

From: Sam Falkner <[email-masked]>
Date: Thu, 22 Jun 2006 07:36:10 -0600

> Where can we find the details on all of this?

I never saw an answer for this; I would like to see the details.

- Sam