Date: Sun, 5 Dec 1999 15:25:05 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: freebsd-arch@freebsd.org Subject: ACL support: semantics vs. syntax in the context of multiple types of ACLs over multiple file systems in the VFS Message-ID: <Pine.BSF.3.96.991205152156.6435A-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
I thought I'd send out an email to discuss some design issues in the implementation of ACL support for FreeBSD. As you probably know, I'm in the process of implementing support for POSIX.1e security extensions to FreeBSD, and this includes support for Access Control Lists for files and directories (and possibly other things :-). The design questions arise because access control, in most cases, is a per-file system design. In FFS, there are file owners, groups, permissions for them, and some additional extended flags. In Coda and AFS, directories have a more extended set of permissions, but individual files don't have individual access control restrictions. In POSIX.1e, ACL semantics define an ACL for each file, and two for each directory (an access ACL, and a default ACL for new children). To a large extent, these ACLs all have the same syntax: a (sometimes restricted) list of ids (of some kind), with a bitmask of rights associated with them. What differs is the exact definition of what the id's refer to, and what the rights are, as well as some restrictions on combinations of ids and rights, as well as ACL targets. This suggests a model wherein the operations exposed to the VFS (i.e., vop_getacl and vop_setacl) require a specific syntax, but leave the specific semantics to whatever layer of the file system stack receives the request. For example, FFS might choose to map ACL operations onto standard attributes/permissions, and only allow ACLs that fit the possible permissions in FFS. AFS might choose to interpret the id's in question as viceids, and the permission mask as AFS permissions. An ACLfs extension to FFS might choose the POSIX.1e semantics. This would leave it up to the calling program to choose the correct type of ACL when setting it for a file or directory, and the requested ACL would be rejected if it didn't match. This leaves opportunities for a number of problems, including confusion by the user, application of an ACL designed for one set of semantics on another set of semantics, etc. Also, it means that some of the POSIX.1e ACL calls (such as acl_valid()) now depend on the target, not just on the ACL itself as a data structure, introducing a lot of complexity. That said, this may be the only way to go. The vast majority of UNIX operating systems have selected either direct POSIX.1e ACL syntax + semantics, or closely related semantics/syntax, including Solaris, IRIX, HPUX, and Linux. But given the complexity of POSIX.1e ACL behavior, and the desire to support other ACL models (such as the intuitive and powerful AFS/Coda model), we would also rather not define a mechanism useful for only one set of semantics. As such, I'm suggesting moving from just vop_getacl and vop_setacl VOPs, to: VOP_ACLVALID(vp, acl, type) VOP_GETACL(vp, acl, type) VOP_SETACL(vp, acl, type) Where type continues to index into the set of available ACLs for the vnode (access, default, etc), and acl is the desired ACL. The acl_valid() POSIX.1e call, currently handled in the library, would now query the vnode it would be applied to to see if the vnode would accept the ACL. The existing POSIX.1e acl_valid() call would simply ask whatever the root file system was whether the ACL was valid for it, and would be depreciated in favor of acl_valid_file() and acl_valid_fd() with specific targets. Currently POSIX.1e defines an ACL entry as being made up of three parts -- an id, id qualifier, and permission set. The id identifies a principal, the qualifier, the namespace for the principal, and the permission set is the mask of rights. POSIX.1e defines several qualifier types, including ACL_USER_OBJ, ACL_USER, ACL_GROUP_OBJ, ACL_GROUP, ACL_OTHER, and ACL_MASK. I believe expanding this namespace is sufficient to take into account differing semantics, although I'm not sure. For example, we could add an ACL_AFS_ID to indicate that the ACL applied to an AFS viceid. Presumably AFS vnodes would reject ACLs with qualifiers other than this, and POSIX.1e file systems would reject AFS entries. Another alternative would be to introduce additional ACL types, but I think that is not intuitive, as the types are currently "access" and "default", and "access" has the same semantics in both POSIX.1e and AFS. The advantage of all this is removing complexity and semantics awareness in the syscall and vnops, but the disadvantage is increasing awareness of semantics in the library -- the awareness in the file system itself was always required. The library would now have to be aware of how to print and interpret text versions of differing ACL types. So when AFS was added, it would just be a kernel module, but also a libc update. We might consider pluggable file system components in libc, but I see that as a hard task to address correctly (although it might be desirable, especially given different principal namespaces and the desire to print principal names in ls -l, etc). I plan to go ahead and reimplement components of the current ACL code to reflect this goal of a semantics-unaware vnops and syscall interface (for example, acl_syscall_set_file will no longer check ACL validity, instead rely on the fs to do this), but would like comments on whether this model suits the needs of the various ACL interface consumers, such as FFS ACL people, AFS people, Coda people, and concerned parties :-). It would also mean we could make use of a better ACL scheme on our own file systems yet support Solaris or IRIX exported file systems with POSIX.1e, and also support the new NFSv4 ACL scheme which is different from any of those mentioned so far :-). I've BCC'd this -security because -security people are interested in ACLs, but it's probably discussion for -arch, so it's actually addressed there. 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-arch" 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.991205152156.6435A-100000>