Date: Sat, 13 Mar 1999 20:39:02 -0600 From: Alan Weber <aaweber@austin.rr.com> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: freebsd-security@freebsd.org Subject: Re: ACLs was disapointing security architecture Message-ID: <19990313203902.B1850@austin.rr.com> In-Reply-To: <Pine.BSF.3.96.990313201103.2563G-100000@fledge.watson.org>; from Robert Watson on Sat, Mar 13, 1999 at 08:20:03PM -0500 References: <19990313190305.A1423@austin.rr.com> <Pine.BSF.3.96.990313201103.2563G-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--> > --> : 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. --> While I recognize the simplicity and usefulness of per-directory ACLs (a --> la AFS and Coda), I suspect that ACLs in the style of POSIX.1e will --> probably achieve greater portability (Solaris, Linux, etc). Since --> permissions are currently on the granularity of files, the POSIX.1e --> mechanism is probably also more consistent with the current permission --> model. I am not suggesting directory-only ACLs but want the file ACL to point to the directory ACL unless explicitly changed on a per file basis. I like the above scheme to reuse ACLs as one change can be efficiently propagated to a huge number of files versus having to fetch/update every file ACL in a directory hierarchy. -- 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-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990313203902.B1850>