From owner-freebsd-security Fri Mar 12 19:58:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 64B5C152FC for ; Fri, 12 Mar 1999 19:58:49 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA82290; Fri, 12 Mar 1999 19:58:28 -0800 (PST) (envelope-from dillon) Date: Fri, 12 Mar 1999 19:58:28 -0800 (PST) From: Matthew Dillon Message-Id: <199903130358.TAA82290@apollo.backplane.com> To: David Scheidt Cc: Robert Watson , freebsd-security@FreeBSD.ORG Subject: Re: disapointing security architecture References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :On Fri, 12 Mar 1999, Robert Watson wrote: : ::The Solaris folk now appear to have ACL support in the base OS install + ::FS. Where did they find the space to store the ACLs? Adding any more : :HP/UX 10.x does ACLs with a second inode per file with ACL. There is a :pointer to the ACL-inode at the end of the normal inode. I think the :reasoning is that most files will have a NULL ACL, defaulting to standard :UNIX permissions, and so the overhead of fetching and writing an additional :block, syncronously, is not excessive. newfs_hfs(1m) warns to allocate :extra inodes if ACLs are going to be used much. This is according to :the inode(4) man page, as I haven't got HP/UX source. If I had, I would :have a system that I could log into the console on. : :David Scheidt 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message