Date: Tue, 20 Mar 2001 12:12:22 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: "Michael C . Wu" <keichii@peorth.iteration.net> Cc: freebsd-fs@FreeBSD.org, mckusick@FreeBSD.org, jedgar@FreeBSD.org Subject: Re: First round review request, ACLs for UFS commit Message-ID: <Pine.NEB.3.96L.1010320114550.77684B-100000@fledge.watson.org> In-Reply-To: <20010320000006.C43637@peorth.iteration.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Mar 2001, Michael C . Wu wrote: > On Tue, Mar 20, 2001 at 12:10:57AM -0500, Robert Watson scribbled: > | For the past few months, we (Chris Faulhaber and myself) have been > > Great work guys! I think the code that you guys produces > is very well written and commented. :) Thanks :-). > | The most recent revision of the ACL code is 0.6.1, available for download > | http://www.TrustedBSD.org/downloads/ > > Just a small question after reading the latest patch. You don't seem to > handle the case where the user forgets that he is not mounting a ACL'ed > filesystem and expecting ACL's to work. There seems to be a default > fallback to old behavior. Is this necessarily good? i.e. Should we have > a default set of ACL's instead? POSIX.1e defines ACLs to act as a superset to normal UNIX file permissions. This means that applications which expect permissions act on ACL'd file systems safely (if a little oddly) without modification. However, it does mean that if applications want to run on both types, and have ACL-aware behavior, they must know how to deal with that. In an earlier iteration, I actually had ACL emulation running over permissions, where it was possible to address permission-based file systems using the ACL interfaces and get the "right" behavior: acl_get_{fd,file}() would return an ACL derived from the permissions, and acl_set_{fd,file}() would accept ACLs that can be represented purely as permissions, returning an appropriate error if not. However, this is actually in violation of the POSIX.1e spec (see discussion on the POSIX.1e mailing list that I host), and so in more recent revisions of the code, emulation is not provided. I was tempted to leave a kernel uption in place that provided emulation on non-ACL file systems, but the impact would be that applications might make incorrect assumptions. I've also been tempted to grab an FFS superblock flag to indicate whether or not the given file system has ACLs enabled, so that ACL policy is available to the file system checker, and allowing distinguishing of the ACL policy from mount policy. However, we only have a very limited number of FFS flags, and an even more limited number of mount flags. In my ideal world, the following FFS flags would be allocated: FS_EA UFS extended attributes are enabled for this file system FS_ACL ACLs are enabled for this file system FS_EANG FFS next generation EAs are enabled for this file system This would allow fsck-time and mount-time activity to be more policy driven (right now, if the UFS_ACL code is enabled and the two posix1e.acl_{access,default} EAs are available, ACLs are available, which is not quite so desirable). It looks like the FFS flags field is only 8 bits though :-(. > Secondly, how does this affect the performance of the filesystem? The performance of the current ACL implementation is primarily driven by the speed of the EA implementation. ACLs themselves add very, very little overhead, it all depends on where and how the ACLs are stored on the file system. The current EA implementation makes use of backing files which are essentially inode number indexed arrays of EA data for each defined EA. There are several performance concerns with this implementation: 1) For a given EA, all access to the EA is channeled through a single vnode lock, preventing concurrent access. (Concurrent access is also limited by the EA implementation, which is something I'm working on fixing by moving to using mutexes and outstanding transaction counts, but it will be a bit before I can get that work finished and evaluated). 2) Locality is not taken into account in storing EAs on disk near the inode they correspond to, introducing potential extra disk seeks. 3) EA and more specifically ACL data is not read in with the inode and so operations that need access to the ACL data may take additional seeks to pull it in. For some initial evaluation of the performance of the current EA mechanism, please see my paper presented at BSDCon 2000. It's available on the TrustedBSD site under Documentation -> Implementation. Note that the interfaces and implementation have evolved somewhat since then, but a number of the general concerns there are still accurate. Because ACL performance is driven by EA performance, and because the EA implementation is cleanly seperated from the ACL implementation (the ACL code accesses the EAs using the normal EA vnode operations on UFS), it's possible to improve ACL performance by improving EA performance. In fact, modulo a bit of fuzz, the cost of ACLs is probably identical to the cost of EAs. As such, the main target for improving ACL performance would be improving EA performance. We hope to have work on this started by late summer, pending the availability of resources to do that. (Hence the FS_EANG flag described above, distinguishing the two implementations). > Also, there are no man pages that I see. There is not currently a good source of documentation for the actual UFS ACL implementation. However, lots of general ACL documentation actually already exists in the base system. Please take a look at: getfacl(1), setfacl(1) acl(3), acl_get(3), acl_delete(3), acl_dup(3), acl_free(3), acl_from_text(3), acl_get(3), acl_init(3), acl_set(3), acl_to_text(3), acl_valid(3) acl(9), VOP_ACLCHECK(9), VOP_GETACL(9), VOP_SETACL(9) What I should probably do to address the lack of UFS documentation is add a README.extendedattributes and README.acls in the ufs/ufs directory, in the style of similar files in ufs/ffs. Also, we should add a UFS man page of some sort that documents various UFS features (including hacks such as SUIDDIR, etc) to make these features more accessible. You might also be interested by: extattrctl(8), getextattr(8), setextattr(8) extattr(9), VOP_GETEXTATTR(9), VOP_SETEXTATTR(9) Note that substantial changes are still underway for the EA mechanisms and interfaces to reflect the needs of applications now being written to use tham (Thomas Moestl has an updated tar that speaks ACLs and EAs, and has noted a number of limitations to the EA interface that need to be addressed). There's also portability work going on with respects to the EA interface that may result in changes to EAs. Let me know if you have any additional questions. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010320114550.77684B-100000>