Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: BSD file system
Message-ID: <2553@auspex.auspex.com>
Date: 21 Oct 89 20:49:29 GMT
References: <1344@accuvax.nwu.edu> <20258@mimsy.umd.edu> <38688@wlbr.IMSD.CONTEL.COM>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Distribution: na
Organization: Auspex Systems, Santa Clara
Lines: 23

>	Another way of looking at the multi-group capability is that
>	a process has a main/primary group - the one listed in the 
>	password file and multiple secondary groups as determined by
>	the group file.  It makes sense to me to use the primary
>	group for purposes of file ownership.

The problem is that it may not be a *valid* way of looking at the
multi-group capability, in that it doesn't fit reality; there may not be
some group that can reasonably act as a user's "primary group".  A user
might work on several things during a session, and not want to use
"newgrp" whenever they change what they're working on to make some
different group be their "primary group".

>       Directories such as /tmp typically are owned by groups of which
>       users are not members, this has led to surprises at least once
>       for me.

In SunOS 4.x and S5R4, the set-GID bit on a directory specifies whether
files created in that directory inherit the group from the parent
directory or get it from whatever of a user's groups happens, by chance,
to be the group in their password file entry.  On such a system, you
could turn the set-GID bit off on "/tmp", or get the system
administrator to do it....