Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Mar 1999 19:03:05 -0600
From:      Alan Weber <aaweber@austin.rr.com>
To:        Freebsd-chat@freebsd.org
Cc:        freebsd-security@freebsd.org
Subject:   Re: disapointing security architecture
Message-ID:  <19990313190305.A1423@austin.rr.com>
In-Reply-To: <Pine.BSF.4.05.9903122220480.23045-100000@nathan.enteract.com>; from David Scheidt on Fri, Mar 12, 1999 at 10:34:46PM -0600
References:  <199903130358.TAA82290@apollo.backplane.com> <Pine.BSF.4.05.9903122220480.23045-100000@nathan.enteract.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 12, 1999 at 10:34:46PM -0600, David Scheidt wrote:
--> 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.  
 
I would suggest that each directory have an ACL inode and that by default each
file will use the inode of the directory ACL inode. This will cause ACLs to 
propagate down a directory tree when subdirectories are created. I generally
administer access rights on a directory basis. I am very used to the NetWare
trustee scheme and find if very convenient to manage user file permissions 
on a directory basis. Would it be possible to increase the granularity of 
the permissions with the ACL scheme (delete, create, rename, write, append, 
read, grant, etc.)? I would be willing to help on implementing ACLs. 

-- 
When I was a kid I had to rub sticks together to multiply and divide numbers. 
A calculator was a job description.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990313190305.A1423>