From owner-freebsd-security Fri Mar 12 20:35: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.enteract.com (thor.enteract.com [207.229.143.11]) by hub.freebsd.org (Postfix) with SMTP id 4873114E2C for ; Fri, 12 Mar 1999 20:35:05 -0800 (PST) (envelope-from dscheidt@enteract.com) Received: (qmail 25781 invoked from network); 13 Mar 1999 04:34:46 -0000 Received: from nathan.enteract.com (dscheidt@207.229.143.6) by thor.enteract.com with SMTP; 13 Mar 1999 04:34:46 -0000 Date: Fri, 12 Mar 1999 22:34:46 -0600 (CST) From: David Scheidt To: Matthew Dillon Cc: Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: disapointing security architecture In-Reply-To: <199903130358.TAA82290@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 12 Mar 1999, Matthew Dillon wrote: : You know, it wouldn't cost too much to implement ACLs with an extra : inode if we implemented an ACL cache, allowing multiple references to : the same ACL inode. When someone changes the ACL associated with a file, : it would hop to a different ACL inode. There'd have to be a mechanism : to prevent excessive fragmentation but I think it would work in general : terms and not even eat that many inodes. Something like this certainly makes sense. You need to keep track of how many files are using that ACL inode, but that is much the same problem as hard links. What I wonder about is what the hit rate is going to be? I am fairly sure that most of my ACLs will be identical, so I suppose the odds of having one in core is pretty high. You would also win on what ever the ACL equivelant of chmod * is. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message