Date: Mon, 15 Mar 1999 13:05:53 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Narvi <narvi@haldjas.folklore.ee> Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <Pine.BSF.3.96.990315125334.11385D-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.3.96.990315095131.13278D-100000@haldjas.folklore.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Mar 1999, Narvi wrote: > Can any ACL scheme that does not *AUTOMATICALLY* apply the ACL to all hard > linked copies of the same file are *FUNDAMENTALLY* broken and IMHO should > be kept far away from FreeBSD. I think we all agree that permissions are properties of file system objects (that is, data pointed to by an inode); ACLs would act as an extension to permissions, and as such also be on a per-inode basis. The ACL behavior being discussed by Peter, et al, has to do with reducing space consumption and improving performance in a real-world implementation, and without breaking these semantics. One example of an optimization was to allow multiple objects to share the same ACL storage, and then use a COW-style approach to reduce storage requirements. The assumption was that most files will not have ACLs attached to them, which seems quite fair to me. Presumably this is all optimization that a little bit of profiling would point to once it's actually implemented. > The present nonsense about hard vs soft link how to partition or not the > hard disk(s) is a clear evidence of the maddness this will lead to. I'm not sure I understand how they are related, other than that inconsistent behavior tends to lead to more mistakes on the part of the user :-). I personally believe that requiring bizarre partitioning to protect users from one-another and the system from the users is not a solution to the hard-link problem; that removing a system setuid binary owned by root/bin should have the KISS expected behavior. Others point out that hard links allow for a performance improvement for some applications due to the use of file system names as database names in a database application, and that it has historically been available, resulting in applications that depend on its availability. The compromise that may be emerging is that both points are valid, and reflect the extremeness of both keeping hard links, or completely discarding them. Wilfredo Sanchez's suggestion concerning limiting the ability to create hard links sounds like a promising middle ground that no one has managed to find a problem with yet, and appears to address the concerns of all involved. I flesh out the semantics a little in Pine.BSF.3.96.990314201139.5121L-100000@fledge.watson.org Is there anyone out there using hard links for database applications (such as mail stores, news stores, etc) who would find their programs broken by this change? 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.990315125334.11385D-100000>