Subject: RE: [nfsv4] NFSv4 ACLs: (acl, masks) pairs

From: "Yoder, Alan" <[email-masked]>
Date: Thu, 31 Aug 2006 15:32:29 -0700

If you have access to Netapp documentation, look
up the docs for mixed qtree security types.

The behavior I'm describing actually comes from
the multiprotocol world--I've boiled it down to
its essentials.

We don't worry about SETATTR | READ_ACL | WRITE_ACL | GETATTR.  
In edge cases it may result in more restrictive 
permissions.  But only admins do this kind of thing--
and that not very often at all--and all they care 
about is that the permissions don't get *less* restrictive.  
I don't know of a single escalation in 10 years concerning 
this particular issue.  

Really, most ACLs are pretty simple.  And most folks only 
set security one way, by habit or consensus or design.  

Alan

> -----Original Message-----
> From: Andreas Gruenbacher [mailto:[email-masked]] 
> Sent: Thursday, August 31, 2006 2:57 PM
> To: Yoder, Alan
> Cc: [email-masked]; J. Bruce Fields; Lisa Week
> Subject: Re: [nfsv4] NFSv4 ACLs: (acl, masks) pairs
> 
> Alan,
> 
> On Thursday, 31 August 2006 02:04, Yoder, Alan wrote:
> > Netapp has had both ACLs and modes for going
> > on ten years.  Our behavior is closest to
> > option 2, and has worked well for us.
> >
> > What we do--boiled down--is to keep track
> > of which is *active*, the ACL or the mode.
> > The active one is determined by which is
> > last set.  This is what is used to determine
> > authorization for file access.
> 
> do you have documentation that you could point me at for 
> understanding what 
> the server enforces and returns after mode SETATTR and ACL SETATTR?
> 
> I would like to understand how this implementation handles 
> sequences of mode 
> SETATTR, and ACL read-modify-write cycles.
> 
> Bruce's question how a mode SETATTR as part of a POSIX file 
> create affects 
> inherited ACLs is interesting case as well.
> 
> > My principal requirement for a mask model is that it is
> > optional.
> 
> I agree.
> 
> 
> Thanks,
> Andreas
> 

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