From owner-freebsd-arch Mon Dec 6 4:22:59 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2DB9614FB0 for ; Mon, 6 Dec 1999 04:22:55 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA26528 for ; Mon, 6 Dec 1999 13:22:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA07618 for freebsd-arch@freebsd.org; Mon, 6 Dec 1999 13:22:54 +0100 (MET) Received: from Thingol.KryptoKom.DE (Thingol.KryptoKom.DE [194.245.91.1]) by hub.freebsd.org (Postfix) with ESMTP id 8988A14FCE for ; Mon, 6 Dec 1999 04:22:41 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.org) Received: (from root@localhost) by Thingol.KryptoKom.DE (8.9.1/8.9.1) id NAA02810 for ; Mon, 6 Dec 1999 13:21:22 +0100 Received: from cirdan.kryptokom.de by KryptoWall via smtpp (Version 1.2.0) id kwa02748; Mon Dec 06 13:21:07 1999 Received: (from root@localhost) by Cirdan.KryptoKom.DE (8.9.1/8.8.8) id MAA24145; Mon, 6 Dec 1999 12:35:42 GMT Received: from Thingol.KryptoKom.DE (Thingol.KryptoKom.DE [192.168.6.1]) by Cirdan.KryptoKom.DE (8.9.1/8.8.8) with ESMTP id HAA12453 for ; Mon, 6 Dec 1999 07:58:54 GMT Received: (from root@localhost) by Thingol.KryptoKom.DE (8.9.1/8.9.1) id IAA24773 for ; Mon, 6 Dec 1999 08:44:19 +0100 Received: from baerenklau.de.freebsd.org by KryptoWall via smtpp (Version 1.2.0) id kwa24295; Mon Dec 06 08:44:06 1999 Received: from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) by baerenklau.de.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA24096; Sun, 5 Dec 1999 21:27:00 +0100 (CET) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: by hub.freebsd.org (Postfix, from userid 538) id 785F71543F; Sun, 5 Dec 1999 12:25:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with SMTP id 4D4551CD73E; Sun, 5 Dec 1999 12:25:13 -0800 (PST) (envelope-from owner-freebsd-security) Received: by hub.freebsd.org (bulk_mailer v1.12); Sun, 5 Dec 1999 12:25:13 -0800 Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id AF98514DCA; Sun, 5 Dec 1999 12:25:06 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id PAA06444; Sun, 5 Dec 1999 15:25:06 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 5 Dec 1999 15:25:05 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message