Default group IDs (was: Re: BSD file system)

[Chuck Karish]

In article <38688 at wlbr.IMSD.CONTEL.COM> sms at WLV.IMSD.CONTEL.COM.UUCP
(Steven M. Schultz) wrote:
>>In article <20258 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>>>In article <1344 at accuvax.nwu.edu> rico at dehn. (Rico Tudor) writes:
>>>	(3) What purpose is served by taking the group ID of a newly
>>>		created file from the parent directory, rather than the
>>>		process?
>>
>>Given that `the process' may be in up to 8 (4.2BSD) or 16 (4.3BSD)
>>groups simultaneously, there is no single correct choice based on
>>the process alone, hence the parent directory rule.

Another reason is that it makes it practical to explain to users how
group IDs are assigned.  There's no standard UNIX utility that tells me
what my effective group ID is.

>	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.   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.

This is fine as long as all you want from groups is a way to have
your daemons cooperate with one another.

The BSD supplementary groups system makes it possible for users to both
protect and share resources.  The mechanism is easy to explain and can
be set up once for each directory tree to be shared, after which it
works transparently for users who are members of the group.  The rules
are:

	- Set the desired group access for the directory to be shared.
	- Don't muck with your umask (must be 002).

This makes it possible for me to be a member of group `graphics' and of
group `geochem', and to share files with each group.  I can do this
without having to remember to reset my effective group ID every time I
write a file in one of the shared directories.  For the ultimate in
convenience, if I am the only member of my own supplementary group,
I can protect files from any group access without changing my umask or
using chmod.

As far as the /tmp example is concerned, there are problems
under the inherit-from-EGID scheme too, unless all users have the same
default group.

        <->-<->->

Some computer system vendors are starting to use a system that allows
anyone to choose whether the parent directory or the effective group ID
of the process will be used in a given directory and its dependent
directories.  The mechanism used is to set the set-GID bit for the
directory.  If it is set, files and directories inherit their group ID
from the parent directory, and new directories have the set-GID bit on
by default.  Fine so far; the user can choose on a directory-by-directory
basis whether to confirm to SVID or BSD/FIPS-151A behavior.

The problem is that the system is not robust.  It requires that the user
and the programmer take extraordinary precautions to avoid resetting the
set-GID access bit for directories.  Scripts and commands that
say `chmod 775 dirname' or `chmod ug=rwx,o=rx' are liable to turn off
the bit, unless the chmod utility is modified to look for it.

In C, the safe way to change access modes for a directory becomes

    stat("dirname", &dirstat);
    chmod("dirname", <my_modes> | (dirstat.st_gid &
        (~(S_IRWXU | S_IRWXG | S_IRWXO))));

where <my_modes> is the desired set of access bits.

Since POSIX 1003.1 leaves the interpretation of the set-UID and set-GID
bits on directories up to the implementation, this approach is a good
idea anyway.  Even so, under the new system for choosing defaults,
existing code that does not take these precautions can break the access
control system inadvertently.  It becomes unworkably cumbersome to make
proper use of supplementary groups.  Users will not notice the problem
unless they actively look for it, and files will not be protected the
way their owners think they're protected.

How else could this be handled?

    - Pick one of the two styles, maybe on a per-host basis, and stick to it.
    - Set the flag by a mechanism that doesn't overload an existing one.
    - Replace the access control system with a more flexible and capable
      (and, undoubtedly, less efficient) one.
    - Have chmod() ignore requests to modify the set-UID and set-GID
      bits on directories.  Provide a separate function to set these bits.

Suggestions, anybody?  Remember, the solution has to work for vendors
who sell to SVID shops, to BSD shops, and to the government, and should
preserve as much existing code and user experience as possible.

	Chuck Karish		karish at mindcraft.com
	(415) 493-9000		karish at forel.stanford.edu