RE: [nfsv4] Files without ACLs?

[wurzl_mario at emc.com]

>> -----Original Message-----
>> From: Yoder, Alan [mailto:agy at netapp.com] 
>> Sent: Friday, July 28, 2006 11:34
>> To: Andreas Gruenbacher; J. Bruce Fields
>> Cc: nfsv4 at ietf.org
>> Subject: RE: [nfsv4] Files without ACLs?
>> 
>> > 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.
We process files with no ACL in a similar way. 

>> 
>> 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
>> 

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