From: Taylor_Tad@emc.com
Date: 04/10/02-02:50:18 PM Z
From: Taylor_Tad@emc.com Message-ID: <6335CBB2F69AD411AD3100D0B7BA38E3040F6B28@CORPUSMX2> Subject: RE: Speaking of ACLs Date: Wed, 10 Apr 2002 15:50:18 -0400 I don't think you can set an "ACE4_FILE_INHERIT_ACE" on a file, therefore if a client did a GETATTR and then a SETATTR, an ACE might transition from inherited to explicit. Although the spec does not say that an ACE once inherited will maintain this distinction, I think it's reasonable to consider that a server would want to keep track of this. -----Original Message----- From: Spencer Shepler [mailto:shepler@eng.sun.com] Sent: Wednesday, April 10, 2002 3:44 PM To: nfsv4-wg@sunroof.eng.sun.com Subject: Re: Speaking of ACLs On Wed, Taylor_Tad@emc.com wrote: > 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. 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. > -----Original Message----- > From: Spencer Shepler [mailto:shepler@eng.sun.com] > Sent: Wednesday, April 10, 2002 3:37 PM > To: nfsv4-wg@sunroof.eng.sun.com > Subject: Re: Speaking of ACLs > > > On Wed, Taylor_Tad@emc.com 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 -- Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:40 AM Z CST