Date:        Tue, 20 Oct 1998 13:35:44 -0400 (EDT)
    From:        Todd Vierling <tv@pobox.com>
    Message-ID:  <Pine.NEB.4.02.9810201331420.8143-100000@duhnet.net>

  | On Tue, 20 Oct 1998, Erik E. Fair wrote:
  | 
  | Primary.  The way most other UNIXen of the world do it.

As soon as you admit to a "magic" gid, you need to add all the baggage to
allow it to be changed.

I don't know how many people here really know the history of gids under
unix - in 6th edition (and before) they were close to useless.   Back
then the number space for uids and gids was just 8 bits, gids were so useless
that many sites simply discarded them to get the extra 8 bits so more users
could exist (the gid and uid fields were treated as a single identifier).

Where that wasn't done there was a "newgrp" command which switched the
user's group from one to another - it was magic in the shell (like login)
which knew to just exec it, rather than fork & exec, and when done, it
just exec'd a new shell (which wasn't so bad in 6th edition where shells
had essentially no internal state anyone cared about, but became horrid with
the smarter shells (csh, and then the 7th edition shell).

In practice, groups were rarely (very very rarely) used for anything at
all, users were basically statically assigned to one, and if the set of users
in a group happened to work together (which could be arranged) then it was
useful - provided that you were only in one such set, if anyone was a member
of disjoint sets of users, the whole group thing simply became unmanageable.

When BSD added the "in multiple groups at once" stuff, the world became
immeasurably simpler, and groups actually became immediately useful, as
you could work with whatever groups you are entitled to use, without having
to remember to swap backwards and forwards all the time.  Believe me, you
don't want to lose that.   Once you have "all groups created equal" you have
to have some other mechanism to figure out which group should be used for
file ownership (that, or allow files to be in lots of groups as well, which is
a major change, and would require quite a lot of mechanism).   The group of
the directory was a great choice - in practice it works well.

On solaris type systems, where SysV.4 wanted to try to remain compatible
with SysV.3 and before (which still had the "one group at a time" setup)
almost everyone I know automatically mounts eveything with the "grpid"
option turned on, which basically forces the setgid bit on on all directories,
as nothing else makes sense (that, or they don't really use groups much
at all).

  | I'm more concerned about files having a group ID other
  | than a user's allowed group IDs;

Why?   Why is creating a file in some random group supposed to be some kind
of a problem?   The only place where things don't always work is /tmp
(and similar).   That is, public directories.   Those are the ones where
your rules would keep the BSD behaviour though - yet they're the one case
where things don't work very well.    That is, if you have your default
umask set to allow group writes, which can be useful if working on a group
project, then when you create files in some public place like /tmp, some
random group tends to get write permission on your file.   That's the place
where it would be nice if it was really some group related to you that was
used.   In practice, as long as you keep those directories owned by groups
which have no members there is no practical problem, but I am not sure that
very many people realise that is a requirement.   In other cases, having files
created in the group of the directory just works.

kre