From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 06:52:48 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC27437B401 for ; Fri, 8 Aug 2003 06:52:48 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0CA143FBF for ; Fri, 8 Aug 2003 06:52:47 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h78DqaAL081725; Fri, 8 Aug 2003 09:52:36 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h78DqaJ8081722; Fri, 8 Aug 2003 09:52:36 -0400 (EDT) Date: Fri, 8 Aug 2003 09:52:35 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert In-Reply-To: <3F335184.A84ECFDB@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Scott M. Likens" cc: current@freebsd.org Subject: Re: ACLS on UFS2 from FreeBSD 5.1-RELEASE install. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2003 13:52:49 -0000 On Fri, 8 Aug 2003, Terry Lambert wrote: > "Daniel C. Sobral" wrote: > > You'll also notice I'm not questioning the _existence_ of ACL. My point > > is that FreeBSD is Unix (no matter what the lawyers say), and people > > don't usually think of ACL when they think of Unix. Ergo, enabling ACL > > by defautl violates POLA. > > Not if you never *set* an ACL on anything. It's only when there are > ACL's set on things that POLA may be violated. > > One presumes that an ACL has to be set on purpose... Well, I think it's more a question of risk with a new feature: it is strue that the intended semantics of the POSIX.1e ACLs is that they are 100% compatible: if you don't have any default or extended ACLs, you should get permissions equivilent to not using ACLs. However, ACLs both rely on UFS2 EAs, which are a new feature, and include a substantial chunk of logic. This suggests that for users never using ACLs, there's a lower risk (in terms of security and stability) by disabling them by default. There's also a small potential performance cost associates with ACLs: you have to access the EAs (generally cheap on UFS2) and do a bit more memory allocation and evaluation. When we ran our original ACL performance benchmarks with UFS1, the difference was fairly measurable for directory-intensive create operations (since the worst case involves accessing two ACLs on a parent directory, and writing two on the child) -- almost all of that cost was the EA cost. With UFS2, EA contents have much more locality to the file, make use of the buffer cache more effectively, etc. All my performance measurements with MAC have seen the EA cost go almost to zero with UFS2, but I haven't rerun the ACL performance tests since the move to UFS2. There are also some application compatibility concerns, which I think is where the POLA element comes into play: if your users do start using ACLs, they may get surprises, which may surprise you :-). I think that having ACLs as an option is lower risk -- in a few minor revisions, once we have more deployed experience, and have rerun the performance tests, and more applications have been adapted (for example, they get backed up by common backup tools) it should be reasonable to enable them by default. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories