Date: Sat, 13 Mar 1999 19:26:52 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Thomas Valentino Crimi <tcrimi+@andrew.cmu.edu> Cc: freebsd-security@freebsd.org Subject: Re: ACL's Message-ID: <Pine.BSF.3.96.990313192214.2563A-100000@fledge.watson.org> In-Reply-To: <wque1H200Uw_0CHFc0@andrew.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 13 Mar 1999, Thomas Valentino Crimi wrote: > Excerpts from FreeBSD-Security: 12-Mar-99 Re: disapointing security > a.. by Robert Watson@cyrus.wats > >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 > >serious data to the inode results in reduced performance as you chew > >through direct block pointers. Adding a new block that stores just ACL > >data sounds feasible, but removes the simplicity of the whole thing and > > Just a quick question on Posix.1e ACL's, are they per-file or > per-directory? Either way, might storing them in the directory > structure (particularly if they ARE per-directory) be feasable. I was > thinking about this back at the beginning of the thread and was thinking > many implementions may have required a 'hidden file' used by the > stacking layer in each directory to store the data. As a matter of > fact, I think that is how one of the older test ACL's layers did it. > I'd think the directory structure would be better, though. POSIX.1e defines one ACL per file, and two per directory--one the actual permissions on the directory, the other the default ACL for new children in the directory. However, due to hard links, ACLs for files probably have to be stored with the file. BTW, I'd really like to get rid of hard links -- they allow users to retain copies of setuid files after the owner thinks they are deleted. I.e., user creates a hard link to /usr/sbin/somesetuidbin to /usr/tmp/mytemp. Now the admin upgrades the machine, thinking they have removed the risk of the now known buggy somesetuidbin. Also, since directory permissions act as a cumlative masks on the permissions of files held in them, it can be hard to revoke access to a file you own--someone else may have hard linked it elsewhere in the fs without your knowledge (something they can do as long as they own the target directory). Given that hard links already cause inconsistent semantics in the name space for users, and aren't properly preserved in tar, etc, I think they don't contribute much. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.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?Pine.BSF.3.96.990313192214.2563A-100000>