Date: Thu, 16 Dec 1999 00:23:24 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: robert+freebsd@cyrus.watson.org Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Request for objections: extended attribute and ACL interfaces Message-ID: <199912160023.RAA26871@usr09.primenet.com> In-Reply-To: <Pine.BSF.3.96.991215143741.22637F-500000@fledge.watson.org> from "Robert Watson" at Dec 15, 99 02:44:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> As previously discussed in some detail on freebsd-arch, freebsd-security, > and posix1e, I have been working on adding support for file system access > control lists (among other things), and the supporting extended attribute > interface required to store additional meta-data in UFS and other file > systems. After a fair amount of hashing out, the interfaces seem to > please most interested parties (i.e., we've verified that the attribute > interface is sufficiently flexible for the needs of the HPFS folk, the > attribute interface provides the functionality for capabilities, acls, > mandatory access control labels, privileged code signatures, etc, and the > acl interface can handle posix.1e acls, as well as providing a mechanism > for managing other acl schemes, such as those in AFS and Coda), and we're > planning to commit these interfaces on Friday, unless objections are > raised. Please note that these are only the interfaces, not the actually > code itself, but standardizing the interfaces (especially vfs calls) makes > it easy to add the code later via kernel modules, and used in other file > systems currently provided by third parties (ARLA and Coda in particular). > > Attached please find four files, text introductions to both extended > attributes and acls, and the sys/ header files providing more detailed > information on the specifics of the interfaces. The extended descriptions > include rationale, information on implementations in other operating > systems, and the interface that descriptions and semantics. I personally have no objection to these interfaces. They seem to cover the problem space that you say that they cover, and they are at worst, harmless. [ ... ] > The UFS EA supporting code would not be committed, as it is experimental > and not well tested. Neither will the UFS ACLs over EAs support. Both of > these will be made available soon, however, and will rely on having > vnops/vfsops/syscalls assigned and available. :-) I object to these patches ever being committed. They are not truly UFS specific, and should be placed in a stacking layer so that they can be applied to any FS via normal stacking semantics. I assume that you are using reserved fields in order to do this? If so, this may justify a genberic interface to get at reserved inode data areas from an overlying layer. However, I would prefer that some other method be used, and that the existing reserved areas be partially used to move the nanosecond time on the modification date off, and fix the Y2038 problem the way that the authors of FFS intended. If there are fields left over after that, then they can be used for specific applications (like ACLs). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912160023.RAA26871>