Date: Thu, 16 Dec 1999 13:50:16 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: David Wolfskill <dhw@whistle.com> Cc: freebsd-fs@freebsd.org Subject: Re: Request for objections: extended attribute and ACL interfaces Message-ID: <Pine.BSF.3.96.991216133154.26813F-100000@fledge.watson.org> In-Reply-To: <199912161545.HAA13748@pau-amma.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 16 Dec 1999, David Wolfskill wrote: > >Date: Thu, 16 Dec 1999 00:10:25 -0500 (EST) > >From: Robert Watson <robert@cyrus.watson.org> > >Reply-To: Robert Watson <robert+freebsd@cyrus.watson.org> > > [OK; if you insist. Was going to reply to -fs, but the Reply-To: > trumped that. -- dhw] David, My intent was not to reject responses to the list, but instead have the response go to my FreeBSD mailbox instead of my primary inbox :-). Reply-to isn't well defined, however, so different mailers do different things. I've CC'd this response to the list. > >First, I'd like to address the issue of whether or not extended attributes > >and ACLs should be made available as a stacked layer service, or whether > >they should be in the base file system. As you read in my detailed > >documentation of these services, there are a number of existing > >implementations that we can reference in looking for advantages and > >disadvantages to various approaches. The previous implementations that I > >have in mind are the following: > > >.... > .... > > In the case of RACF (IBM's product that implements SAF; there are other > products, from other vendors, that also do implement it, though probably > in different ways; I never used them), the ACLs are maintained in a > "database" -- thus, entirely separate from the file system > implementation itself. I believe that HP/UX does this, upcalling to a userland database process to maintain security tags for files. It has both advantages and disadvantages. Given functional layering, it's easy to imagine a layer that upcalls to a database for property changes, including extended capabilities, etc. > One of the more interesting aspects of the use of a separate database > for the ACLs (called "profiles" in RACF) is that they permitted a > certain amount of "wildcarding" (or "globbing") -- referred to as > "generic profiles" in RACF. > > This was handy, in that one could establish a baseline ACL, and then > override it with more specific ACLs as required. > > In thinking about extending this to a hierarchical file system, it would > be analogous to specifying an ACL based on a (possibly globbed) > pathname. And I find it of some interest that one could well have > multiple pathnames that point to the same inode (and thus, to the same > data), but since the paths are different, it could be possible to have > different ACLs that apply. > > I find this similar to the notion that an executable could be exec()ed > via different pathnames, and might alter its behavior in accord with the > pathname by which it was invoked: yes, it complicates things to some > extent, but it provides a level of flexibility that is appealing (well, > to me). (Of course, in order for this to be at all rational, it would > need to only work with hard links, and the link() call would need to > check the ACL for the subject of the link, to verify that the link() is > to be permitted. Well, *maybe* there's a way for a symlink to work, but > I see that path fraught with danger, especially since the subject of a > symlink doesn't need to exist ahead of time... so someone could create a > "stealth" symlink to bypass a (subsequently-instantiated) ACL.) This actually sounds a lot like the Trusted Path Execution (TPE) patches made available by (I forget who, unfortunately) a while ago. Essentially, it allows only certain paths to delegate rights, and associates capabilities with those paths, as opposed to with the objects themselves, at execution. This is an interesting and useful idea, but indeed is quite semantically different from the notion of per-file capabilities and ACLs. This isn't to say it isn't useful, but because the VFS file semantics support relatively easy namespace manipulation, especially of the name provided to binaries executing, the executables have to be very careful what they do with their rights, and with permissions on all directories leading to the executables. This namespace-based ACL allocation to objects would, however, make a lot of sense as a file system layer with static data--more sense than the attributes/acl approach as imlpemented in a layer as Terry suggests. Because the ACLs are tied to lookups as opposed to objects, there is no correctness or inter-layer consistency factor to consider. However, it's certainly not POSIX :-), and gets rid of the flexibility to relocate things regardless of names -- for example, moving a user's home directory from /home/user to /homea/user does interesting things to ACLs in effect for the space. With ACLs bound to objects, this is never a problem. > But in general, the idea of *not* requiring a one-to-one correspondence > of ACL to object protected would seem to be a big win. Yes--if only from a space optimization perspective. One simplification POSIX.1e provides us with is that objects do not have to have ACLs--they can just have permissions. Another is that namespace recursive permissions are used--as with permissions today on directories, ACLs in directories leading to the file provide some sorts of masking of object availability. If you throw out hard links, both today's directory permissions and tomorrow's ACLs become far more consistent in behavior. > Anyway, I can certainly go into additonal levels of detail about what I > recall of RACF; I used to install it & write MVS system exits that used > it. Once layering works adequately, it would be interesting to write a layer that provides this service. I guess an obvious question is how you represent ACLs for submission to the layer: right now setting the ACL either occur on a file descriptor for the directory, or by a pathname, from the perspective of userland. These are both converted to vnodes for submission to the FS, and the ACL is passed in. It's not clear you can distinguish the namei() used by acl setting from the namei() used for file opening, so you'd probably need a new interface; alternatively, we hide your new form of ACL in an ACL structure and apply it to the directory that is the root of the region covered by the ACL. A question that comes to mind is how you deal with file system boundaries and mountpoints--I guess the safest assumption is that the layer covers the whole namespace, and you just have a submit_acl(root, aclstring) where aclstring is the glob. 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-fs" 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.991216133154.26813F-100000>