RE: [nfsv4] Files without ACLs?
"Yoder, Alan" <agy@netapp.com> Fri, 28 July 2006 15:31 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6UIo-0005cz-IK; Fri, 28 Jul 2006 11:31:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6UIm-0005VQ-ST for nfsv4@ietf.org; Fri, 28 Jul 2006 11:31:00 -0400
Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6UIk-00064r-Hz for nfsv4@ietf.org; Fri, 28 Jul 2006 11:31:00 -0400
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2.netapp.com with ESMTP; 28 Jul 2006 08:30:54 -0700
X-IronPort-AV: i="4.07,192,1151910000"; d="scan'208"; a="396205074:sNHT58174756"
Received: from svlexc03.hq.netapp.com (svlexc03.corp.netapp.com [10.57.156.149]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id k6SFUn96021012; Fri, 28 Jul 2006 08:30:49 -0700 (PDT)
Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexc03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 28 Jul 2006 08:30:47 -0700
Received: from exsvl02.hq.netapp.com ([10.56.8.60]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Jul 2006 08:30:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nfsv4] Files without ACLs?
Date: Fri, 28 Jul 2006 08:33:53 -0700
Message-ID: <992BA60650F1584BA63E339312CE420305B94E53@exsvl02.hq.netapp.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] Files without ACLs?
Thread-Index: AcaxHOZnaY/5sXffT32tk6Ld2Vgy5AAJZYfQ
From: "Yoder, Alan" <agy@netapp.com>
To: Andreas Gruenbacher <agruen@suse.de>, "J. Bruce Fields" <bfields@fieldses.org>
X-OriginalArrivalTime: 28 Jul 2006 15:30:46.0709 (UTC) FILETIME=[CC10C650:01C6B25A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: nfsv4@ietf.org
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
Errors-To: nfsv4-bounces@ietf.org
> 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@netapp.com Technical Staff Network Appliance, Inc. 408-822-6919 =============================================================== > -----Original Message----- > From: Andreas Gruenbacher [mailto:agruen@suse.de] > Sent: Wednesday, July 26, 2006 6:31 PM > To: J. Bruce Fields > Cc: nfsv4@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@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
- [nfsv4] Files without ACLs? Andreas Gruenbacher
- Re: [nfsv4] Files without ACLs? J. Bruce Fields
- Re: [nfsv4] Files without ACLs? Andreas Gruenbacher
- RE: [nfsv4] Files without ACLs? Yoder, Alan
- RE: [nfsv4] Files without ACLs? wurzl_mario