Date: Fri, 27 Dec 1996 23:00:57 -0500 From: Bakul Shah <bakul@plexuscom.com> To: hackers@FreeBSD.ORG Cc: Terry Lambert <terry@lambert.org> Subject: Re: multi-group file access techniques (repost) Message-ID: <199612280400.XAA00822@chai.plexuscom.com> In-Reply-To: Your message of "Fri, 27 Dec 1996 16:49:34 MST." <199612272349.QAA25559@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes:
> Using NULLFS, prototype an FS layer that sits on top of an FS using the
> following user name space intrusions:
...[`intrusions' on the ACLs via a special FS layer deleted]...
> You now have *real* ACL's.
Here is another idea -- perhaps more in `the spirit of Unix' (IMHO).
or plan9.
* Implement a group FS layer. The group-fs allows group membership
related operations via the familiar file system interface. For
example,
# enable group-fs
$ mount groupfs /system/groups
# Add a new user to the wheel group
$ cd /system/groups/wheel # each group has its own dir.
$ ls
root
$ touch joe # joe must be a known user
$ ls
root joe
# Create a new group
$ cd /system/groups
$ mkdir my-group
# Use this new group
$ cd $HOME
$ chgrp my-group file1 file2 dir ...
Treating groups as directories also solves the problem of who can
add/delete group members (depends on the permission bits of the
group dir).
If a group is added as a subdir in another group dir, the first
group's members are automatically members of the latter group.
In this scheme a file's gid maps on to an i-number of a group dir
(on the group-fs). Checking group permissions on a file `foo' is
then equivalent to a lookup for an entry with ino == user's id,
starting with a group dir whose vnode is derived from foo's gid.
There are some obvious problems with the scheme as sketched out
(afterall, I thought of this scheme only about 15 minutes back) but
I believe they ought to be solvable.
If you want `path-access-control' where accessability of a file is
a function of the path used (I think this is what Terry calls
reverse inheritance), the group-fs would need to be a bit smarter.
Perhaps a validating program or a list of regular expressions can be
stored in the group dir.
I prefer controlling ACLs via groups in this way because
a) 4 billion groups ought to be enough for a while and if you want
you can put each file in a different group.
b) Multiple files can share the same group memebers. In an ACL
per file approach you may need to create separate lists.
c) The above scheme can be used, for instance, to tighten control
over exisiting collection of files by changing existing group's
membership but *without* changing file inodes.
d) Finer grained control over who can change group membeship etc.
and yet a whole group of files can be simulteneously controlled.
To make this really effective I'd also want a user-fs, to keep track
of users. This would make system administration easier too!
# enable user-fs
$ mount userfs /system/users
# add a new user
$ cd /system/users
$ mkdir bubba # this will automatically create files in
# this new dir based on some default dir.
$ ls bubba
gid gecos home limits passwd shell uid ...
The same sort of thing can be done with a number of other /etc files.
An FS abstraction allows you to take advantage of other features
available on files (such as explicit control and distribution of
responsibility of who can add/delete instances of some object-type).
Also, file paths map nicely to URLs! :-)
Assuming, of course, all of this can be done reasonably efficiently
(and if the FS API is light-weight enough).
Comments?
-- bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612280400.XAA00822>