smb@ulysses.UUCP (12/10/83)
I've been trying to figure out how to use the group permission scheme implemented in 4.1c/4.2 bsd. For those of you who haven't seen it yet, each user may be in up to N groups at once (default max is 8), plus an "accounting group" -- the traditional group listed in /etc/passwd, and used by setgid programs. Files are created in the group of the directory containing them; this means that if, for example, /usr/src is group 'staff', any new files created in /usr/src will be in group staff, regardless of the gid of the creator. The chgrp command (which is setuid) will let you change the group of any of your files or directories to any group you're a member of. Permissions, though, are still affected by umask, and therein lies the rub. Suppose my home directory is group 'other', but /usr/src is group 'staff'. Files that I create in my home directory should be created with a umask of 022 -- since I don't want random folks scribbling on my files -- but anything I add to /usr/src should be umask 002, since other staff members should be able to modify those files. What's really needed, it seems, are per-gid umasks -- a horrible concept -- or per-directory umasks, similar to Multics' "initial access control lists". Both, of course, would require kernel-hacking which I don't want to do. The scheme I've tentatively come up with is to assign each user a gid equal to his/her uid (with the appropriate /etc/group entry), and make the default umask 002. Thus, for files not part of a shared project -- say, one's home directory -- the 002 access means that no one else will be able to get to them anyway. But if that user is part of any specialized groups, and has a directory belonging to that group, files created in it will be shared. Comments? (One objection I've considered and dismissed is that it makes /etc/group too long. But its length is (mostly) bounded by /etc/passwd, and we're willing to live with that.) --Steve Bellovin (ihnp4,ucbvax,decvax,unc}!ulysses!smb
wls@astrovax.UUCP (William L. Sebok) (12/12/83)
We have a 4.1 BSD kernel with hacks for accounting (no flames.. I bitterly
fought it and lost). Each process has three id's uid, gid and the aid
(accounting id). The purpose of this is to separate accounting from file
permissions. A login name can charge its time to one of several "accounts",
which one selects by answering a "Charge: " question given after having
successfully given the password. There is no awkwardness of transferring files
between accounts because the "aid" is not associated with any file permissions
or ownerships.
When I saw the "accounting" groups in 4.2 BSD I was hoping that it was
something of the same sort. Unfortunately it is not. It looks like the 4.2
kernel is also going to get hacked. I wish that a disentangling of accounting
and file permissions could be made part of the "official" Unix (whatever that
is).
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,kpno,princeton}!astrovax!wlsstein@fortune.UUCP (12/22/83)
#R:ulysses:-73400:fortune:11600036:000:287 fortune!stein Dec 21 17:09:00 1983 Another way around the umask problem is to create a group named "nogroup" which has no members. A user can then set a directory to this group and not worry about the 002 umask for files created there. And it only adds one extra group to /etc/group. Mark Stein Fortune Systems