RE: [nfsv4] Files without ACLs?

["Yoder, Alan" <agy at netapp.com>]

> Ack. My point was that we do not want to have it that in case 
> of an empty ACL, 
> the mask attribute must be considered to determine access.

Why not?

In a real ACL-using FS, empty ACLs are extremely rare.  Only
Administrator/root can access such a file (and even then may 
only be able to take ownership).   

In our current FS, there's a difference between an empty
ACL and no ACL (at least in "mixed qtrees", which best correlate
to the proposed system, I think).  A file with no ACL is treated 
as a Unix file, and the mode/perms are used to determine access.
A file with an empty ACL is treated as above.

Not sure if this helps, but that's how we've done it for a
good while.

Alan

===============================================================
Alan G. Yoder                                    agy at netapp.com
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================





> -----Original Message-----
> From: Andreas Gruenbacher [mailto:agruen at suse.de] 
> Sent: Wednesday, July 26, 2006 6:31 PM
> To: J. Bruce Fields
> Cc: nfsv4 at ietf.org
> Subject: Re: [nfsv4] Files without ACLs?
> 
> On Wednesday, 26. July 2006 22:50, J. Bruce Fields wrote:
> > On Wed, Jul 26, 2006 at 12:25:46PM +0200, Andreas Gruenbacher wrote:
> > > The two strategies I can imagine are to somehow indicate 
> to the client
> > > that a particular file "has no ACL", or to make up an ACL which
> > > represents the file mode. This case is different from an empty
> > > (zero-entry) ACL, for which RFC3530 defines that the 
> result is undefined.
> > > (I interpret undefined as either always denied or always 
> allowed, rather
> > > than defined by the mask attribute).
> >
> > It could mean whatever you want, but I think every current
> > implementation probably takes that to mean a deny, and the 
> current 4.1
> > draft says it's a deny.  (Assuming it's just a case of 
> reaching the end
> > of the ACL while still having permission bits neither allowed nor
> > denied.)
> 
> Ack. My point was that we do not want to have it that in case 
> of an empty ACL, 
> the mask attribute must be considered to determine access.
> 
> Andreas
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4