Date: Mon, 29 Nov 1999 11:13:45 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Harris K Telemacher <rearl@user2.teleport.com> Cc: freebsd-security@freebsd.org Subject: Re: ACLs for FreeBSD (was: Re: ps on 4.0-current) (fwd) Message-ID: <Pine.BSF.3.96.991129110747.12803B-100000@fledge.watson.org> In-Reply-To: <19991129034310.F6389@user2.teleport.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Nov 1999, Harris K Telemacher wrote: > This is great work and something I would be willing to beta test, but > I might prefer it to be developed as new filesystem, like a cloned, > feature-added version of FFS. Call it p1efs or something, leave the > BSDisms in place with FFS, and start working on ACLs and the other > worthwhile POSIX extensions. This may help smooth over a few issues such > as ACL/MAC storage, but then again it may create other problems. Now that > I reread your message, I see that you may have thought about doing this, > so if you have, then let me know why it's going in this direction, > since I'm not as familiar with the kernel's filesystem layers as I am > with some of the other bits. I agree entirely, and we have discussed these various options in some depth on various mailing lists (including the POSIX.1e list). The general conclusion has been that in the short term, defining the VFS (Virtual File System) interface for ACLs is a good step forward. Some file systems already support ACLs (such as Coda and AFS) so should give us a good ideas as to whether the library and kernel support code is sufficient. Then once that was finalized, we could try and push ACL support into existing file systems that both do and don't support ACLs. Recently I made a post of posix1e documenting the ways that different file systems have integrated ACLs and other extended data. The most flexible way was in IRIX XFS, where a general-purpose attribute mechanism is provided, allowing the tagging of files with arbitrary data by the kernel, including things such as ACLs and MAC tags. Then there's the Solaris/Linux approach of a specific-purpose solution (Solaris: a second inode for each file, Linux: an extra block pointer). I lean towards an FFS2 with attribute support, as well as possibly transactional meta-data support to keep attributes and inodes in sync to prevent crashes from allowing access violations or inconsistency. All this becomes possible only once a general ACL interface and so on are defined and implemented, which is now becoming the case. Hopefully this will prompt work by others who are more fs-centric. > I have not downloaded the code for a look yet, but I will soon, so stand > by for more suggestions and hopefully some patches, if I get the time > to work on it (I'm running primarly OpenBSD, also NetBSD and even an > old FreeBSD system at home.) You may want to wait for 0.1.1 which I hope to bring out in a day or two -- it will be based on -CURRENT and Assar's patches, as well as have some improvements (currently my group behavior in the default ACL evaluation is not to spec, using first match not best match behavior). However, feel free to peruse the existing code to see how it could fit into the other *BSD frameworks. I'd love to have consistent ACL behavior across the various BSDs, which is in part the goal of POSIX.1e. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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.991129110747.12803B-100000>