Subject: RE: Speaking of ACLs

From: [email-masked]
Date: Wed, 10 Apr 2002 15:39:24 -0400

That seems problematicin the face of inheritable ACEs.  Is there some
fundamental reason why this is the case?  It would seem to be an easy
extension to how ACLs are set.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, April 10, 2002 3:37 PM
To: [email-masked]
Subject: Re: Speaking of ACLs 

On Wed, [email-masked] wrote:
> Since NFSv4 allows ACEs to be inherited from a parent directory, shouldn't
> the SETATTR operation allow setting ACLs to either add to or supersede an
> existing ACL?  Just because you want to add something to an ACL doesn't
mean
> you want to remove the ACEs that were inherited.   I don't think I saw
> anything in the spec other than setting (presumably replacing) an ACL.

The NFSv4 attribute model is replace-only and hence this applies to
the ACL attribute.

-- 
Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 10 Apr 2002 14:43:38 -0500

> extension to how ACLs are set.

The client can GETATTR, modify acls, SETATTR, right?

If the model were to change for the ACL attribute, what add "modes"
should there be?  Append, pre-pend, sort?  Based on the issues that
have been discussed with respect to ordering an interpretation it
seems best to leave the model as it is until we have more concrete
information from implementation experience.

-- 
Spencer