From owner-freebsd-arch Fri Oct 22 7:29:26 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 A555514C9E for ; Fri, 22 Oct 1999 07:29:21 -0700 (PDT) (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 QAA11915 for ; Fri, 22 Oct 1999 16:29:20 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA00261 for freebsd-arch@freebsd.org; Fri, 22 Oct 1999 16:29:19 +0200 (MET DST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4CA0914E1D; Fri, 22 Oct 1999 07:25:53 -0700 (PDT) (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 KAA52739; Fri, 22 Oct 1999 10:25:52 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 22 Oct 1999 10:25:52 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: freebsd-arch@freebsd.org, freebsd-security@freebsd.org Subject: VFS, vnodes, and ACLs: Thoughts and Questions on integrating , POSIX.1e ACLs into FreeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm in the process of reviewing the POSIX.1e draft to being implementing ACLs. As you're probably aware, all other major UNIX distributions have extended ACL support available, if not turned on in the default file system. For those that have been following the POSIX.1e list recently, I've posted a summary of some of the ways they get them into the FS (IRIX: has general purpose attribute support; Solaris: an extra inode and file structure for each ACL; Linux: an extra block pointer in the inode) -- and now I have some questions about adding this support to FreeBSD. The first question has to do with integration into the vnode as vnops. The closest current vnops are vop_getattr and vop_setattr -- getting and setting standard file attributes (mode, size, modification dates, et al). It makes sense conceptually that the ACLs might be included in this attribute information, as a substructure or pointer or the like. However, because ACL support across different file systems is nebulous and likely to be inconsistent for a long time (if not forever), it makes sense to think of getting and setting ACLs as vnops themselves -- for this purpose on an experimental kernel I have introduced vop_getacl and vop_setacl. This allows the ACLs to be exposed in their own right to the layering and file system behavior -- file systems that don't implement ACLs or don't know about them return EOPNOSUPP, and a layered file system could easily choose to intecept ACL changes explicitely and implement tham in a union or the like. If the vnode interface is aware of ACLs, this raises the format and semantics of ACL structures exposed in vnops, as they should/must be consistently interpreted and implemented. My temptation is to make POSIX.1e ACLs part of the vnode-aware types -- the interface seems to be standard across the various UNIX implementations, and in this sense it's similar to the mode, uid, gid values in vattr that we also expose non-opaquely. For reference, here's a simplified view of how most platforms have chosen to represent ACLs for their kernel syscall interface: They either define an acl_t structure referring to an array of ACL entries (acl_entry_t), or they directly pass around arrays of acl_entry_t's via syscalls. For example, the LINUX (and Solaris) ACL syscalls look like this: int acl(const char *pathp, int cmd, int aclcnt, acl_entry_t *aclentp); int facl(int filedes, int cmd, int aclcnt, acl_entry_t *aclentp); typedef struct acl_entry_t { int a_type; uid_t a_id; mode_t a_perm; } acl_entry_t; The various POSIX.1e interfaces refer instead to acl_t's which are presumed to store references to acl_entry_t's, so you could also imagine a syscall interface referring to an acl_t structure, and without the count variable. typedef struct acl_t { int entries; int size; acl_entry_t *entp; } acl_t; This provides a general ACL structure with a pointer to an array of acl_entry_t's, or individual "this user/group gets this right". The other approach to doing this might be the approach of: typedef struct acl_t { int entries; int size; acl_entry_t ent[3]; }; /* 3 is the minimum entries in an ACL */ This is where the aclcnt argument could come into play. Which would remove indirection in the vnode-aware structure and therefore perhaps be "nicer". Either way, it looks like acl_t's would be the best type (in whatever form) to pass ACLs around in the kernel with, as they can contain data describing the array of acl_entry_t's, and not just the entries as a direct array would do. This vnode approach then moves the responsibility for implementing ACLs to individual file systems -- a layer could choose to take advantage of some existing mechanism (extrended attributes) to store them. There's also the issue of evaluation -- right now, my understanding is that the vnode call vop_open is implemented by each file system, which may return EPERM if it desires. POSIX.1e describes an evaluation procedure for ACLs -- preusmably providing a set of common functions all file systems (optionally) can use for ACL evaluation makes sense -- this would mean (for example) that the same ACL evaluation routines could be used in FFS and MFS without replicating code all over the place. The other option is to treat ACLs as opaque and fs-specific, but that makes layering a lot less useful for implementing ACLs. On the other hand, it would also force us to follow the POSIX.1e model for ACLs, which while popular might benefit from improvement? Anyhow, thoughts on the topic would be much appreciated. I have not yet tried to address the issue of integrating ACL storage into various file systems. A first bet might be NFS as (apparently) there are NFS extensions for passing ACLs from ACL-aware servers (such as Solaris, IRIX, and presumably Linux sometime soon as they're talking about it on their acl-develop mailing list). Another choice might be Coda/AFS which both support ACLs, albeit not POSIX.1e-style ACLs. Some conversion between the two could be done for the purposes of inspecting ACLs, although I think not setting (AFS groups work quite a bit differently than POSIX-style groups, as they allow users to create them on the fly and modify them as they see fit). 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