Date: Mon, 06 Dec 1999 17:27:35 -0700 From: Brett Glass <brett@lariat.org> To: Robert Watson <robert+freebsd@cyrus.watson.org>, freebsd-arch@freebsd.org Subject: Re: Extended File Attributes for FFS (request for design comments) Message-ID: <4.2.0.58.19991206172414.03e973a0@localhost> In-Reply-To: <Pine.BSF.3.96.991206180648.12192B-100000@fledge.watson.org >
next in thread | previous in thread | raw e-mail | index | archive | help
I seem to recall that HP/UX does something very much like what you describe. (Actually, they get even fancier; they can cause you to open or see a DIFFERENT FILE depending on what architecture you're running. This trickery is done via environment variables.) Their file system extensions might be worth a look. --Brett At 04:21 PM 12/6/1999 , Robert Watson wrote: >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 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?4.2.0.58.19991206172414.03e973a0>