Date: Fri, 12 Mar 1999 19:58:28 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: David Scheidt <dscheidt@enteract.com> Cc: Robert Watson <robert@cyrus.watson.org>, freebsd-security@FreeBSD.ORG Subject: Re: disapointing security architecture Message-ID: <199903130358.TAA82290@apollo.backplane.com> References: <Pine.BSF.4.05.9903122021400.12879-100000@nathan.enteract.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903130358.TAA82290>