group id's and UNIX protection

[utzoo!decvax!ucbvax!unix-wizards]

>From walton at LL-XN Mon Oct 19 11:22:23 1981
Since the problem of multiple group id's has been raised, I might
as well give up my vow of silence on protection issues and share
with you some conclusions, most of which I came to years ago, about
the UNIX security system.  Maybe I might goad the powers at be
into implementing something I would actually find usable.

In the first place, the UNIX security system is not very good.

Problem 1 is that few people want to waste time running newgrp.

Problem 2 is that newgrp is not orthogonal to normal program writing:
if you write a program that needs files from multiple sources
you do not want to call newgrp in the middle of the program- the security
system should be invisible to programmers.  You get terribly fouled
up as soon as different groups start overlapping and want to have common
members, or programs that they have a common interest in maintaining,
or data they want to share with each other but not the whole world, etc.

Problem 3 is that the current process is not a good place to get
the group id for a new file.  The containing directory is a much
better place.

Problem 4 is that there is a confusion between accounting, which
probably should be a user id function, and security, which probably
should be a group id function.

Clearly the solution, and the only one as far as I can see, is to
have multiple group id's per process with files inheriting their containing
directory's gid (and having only one gid).  Supergroup should
be implemented, superuser abandoned, and user id's become primarily
an accounting function.  Set group id has to become additive:
you add to the list of process group id's temporarily.
Set user id can be as currently; it changes who gets charged.
Along with each gid in its list of such a process should have
a set of permissions, so that it can, say, read with some gid
but not write with it.

The login uid should should also be one of the gid values
so it may retain the security function of protecting files completely
private to a single user, like .mail, but will not be removed from the
list of effective gid's when the process changes its uid for
accounting reasons: that is, the process uid will cease to have ANY
security function but the login uid will initially be both the process
uid and a process gid.

One important principal is to insist that programs should not have to
know about the protection system in order for humans to be able
to put locks on files and pass out the keys, as it were.

Another important principal is that it should be very easy to give
any user enough keys so that he never has to bother with the
protection system, without giving him keys to the whole world.

And I guess the MOST important principal is that protection had better
be very automatic, for aside from putting a lock on the very outermost
door its hard to justify wasting any manpower at all on it to
people who are trying to get work done.

I have NO intention of implementing anything.  Enjoy!