Date: Mon, 6 Dec 1999 18:21:16 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: freebsd-arch@freebsd.org Subject: Extended File Attributes for FFS (request for design comments) Message-ID: <Pine.BSF.3.96.991206180648.12192B-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Adding trusted operating system behavior (MAC, Capabilities, ACLs, etc) to FreeBSD requires that additional state be maintained for files and directories. For example, in POSIX.1e, an ACL is maintained for each file, and two for directories. Similarly, a MAC label is required for each file and directory in the file system. This, of course, raises the issue of where to keep this data. Various operating systems take various approaches -- I posted a fairly comprehensive list of OS choices on the posix1e mailing list a couple of months ago while looking for a solution. They vary from extra block pointers, additional inodes, userland databases with upcalls, etc. The cleanest solution, in my view, was the IRIX XFS extended attribute code. Named extended attributes are defined for each inode, and may contain arbitrary information. Needless to say, there is performance overhead associated with this approach, but it seemed the most flexible from a new feature standpoint, and still allowed for optimization, etc. As such, I'd like to suggest a similar mechanism for our VFS, along with a hacky implementation for FFS that is sufficient to back the ACL, Capability, and MAC support until we have functioning layering. Even after layering, the VFS vnops still need expanding to support this functionality, so that would stick around. Two new vnops would be introduced for managing extended attributs: vop_setextattr(vp, name, buffer, len) Set an extended attribute: vp vnode pointer to set attribute for name attribute to set buffer data for attribute value len length of data Returns 0 on success, otherwise an error. buffer of size len must fit into the preconfigured attribute size. vop_getextattr(vp, name, buffer, &len) Get an extended attribute: vp vnode pointer to get attribute fur name attribute to get buffer buffer for data len input: length of buffer; output: length of data Returns 0 on success, otherwise an error. buffer of size len must be able to hold all of preconfigured attribute size, or an error will be returned. My assumption is that these attributes would be of fixed size, and a predetermined maximum size. This is consistent with the various security attributes we've looked at, and some of the none-security uses of attributes. Each file/directory would have a set of named attributes, settable and retrievable using this interface. Decent names might include EXTATTR_ACL_ACCESS, EXTATTR_ACL_DEFAULT, EXTATTR_MAC_LABEL, etc. You can easily imagine backing this with a layered fs implementation on top of FFS--for example, an ACLfs that converts get/set ACL calls to extended attribute calls, and hooks open(/etc) to make use of the ACLs for access control (this is very similar to work done by Jeff Weidner at UCLA as part of the layering work). However, the ACL code is ready to go today, and needs backing to get it to work, so waiting for layering is probably not an option. As an interim solution, I'd like to implement an attribute solution for UFS (and hence FFS, MFS) which, like quotas, makes use of files off of the file system root. Each named attribute would be backed by a file attribute/name, and effectively be an array of attribute data, indexed by inode number. Hooks, as with quotas, would be stuck in inode allocation and freeing, etc. ACL calls on UFS would be converted, within UFS, to attribute calls, etc. This solution is not as clean as the layering solution, but would be relatively quick to implement. This raises questions such as how to runtime configure support for attributes, ACLs, etc. My guess is that a mount flag, extattr, would be defined to enable support for extended attributes, and automatic loading of attribute data from attributes/ off of the fs root. It might be desirable to seperately enable ACL support (and so on) via other flags, although this is less clean. Quota's define a quotactl syscall/vop to manage UFS quota behavior, but that seems not-so-general. I'm not sure that there is currently a mechanism to push configuration information down the VFS stacks to specific file systems, other than the mount info. One possibility would be to add a control MIB of some kind and a management call in VFS, or just to use sysctl and go outside the framework of VFS. These areas where I'd much appreciate comments. I would like to start implementing this later this week, starting with VFS calls (the above are my proposed prototypes, but suggestions are welcome) followed by a UFS implementation RSN so that we can back ACLs, Capabilities, and MAC onto it and make some more progress in getting these working. Thanks, 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.991206180648.12192B-100000>