From owner-freebsd-security Sat Mar 13 18:39:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from aauu.aaweber.com (cs9340-48.austin.rr.com [24.93.40.48]) by hub.freebsd.org (Postfix) with ESMTP id CE96D14DAB; Sat, 13 Mar 1999 18:39:24 -0800 (PST) (envelope-from aaweber@austin.rr.com) Received: (from aaweber@localhost) by aauu.aaweber.com (8.9.1/8.9.1) id UAA01893; Sat, 13 Mar 1999 20:39:03 -0600 (CST) Date: Sat, 13 Mar 1999 20:39:02 -0600 From: Alan Weber To: Robert Watson Cc: freebsd-security@freebsd.org Subject: Re: ACLs was disapointing security architecture Message-ID: <19990313203902.B1850@austin.rr.com> References: <19990313190305.A1423@austin.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Robert Watson on Sat, Mar 13, 1999 at 08:20:03PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --> > --> : 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