Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!stanford.edu!morrow.stanford.edu!pangea.Stanford.EDU!karish
From: karish@pangea.Stanford.EDU (Chuck Karish)
Newsgroups: comp.unix.aix
Subject: Re: Directories Setting GID...
Summary: Compatibility hack
Message-ID: <1991May14.214811.11774@morrow.stanford.edu>
Date: 14 May 91 21:48:11 GMT
References: <715@aos.brl.mil> <7559@awdprime.UUCP>
Sender: news@morrow.stanford.edu (News Service)
Organization: Mindcraft, Inc.
Lines: 26

In article <7559@awdprime.UUCP> web@farpoint.austin.ibm.com (Bill Baker) writes:
>The set-gid bit determines how the group id of new files is set.  If the
>set-gid bit is on, the file inherits the group id from the directory.  If
>not, the file inherits the group id from the effective group id of the
>process.
>
>This is a compromise between BSD and SysV.  I believe this functionality
>is emerging as a standard; it is now part of the third edition SVID.

It's there because FIPS 151-1 requires the BSD behavior, which is
incompatible with the default SysV behavior.

It meets the letter of the FIPS, but does not provide a stable
environment for group sharing of files, as a real BSD system would.
The problem is that any user can inadvertantly turn off the set-gid bit
with a simple chmod and break the inheritance properties of the changed
directory and any directories later created in it.

Some vendors have recognized this problem and made provision for
enforcing the BSD behavior.  SunOS, for example, allows the
administrator to turn on the BSD behavior for an entire filesystem with
the 'grpid' option to mount(8).
--

	Chuck Karish		karish@mindcraft.com
	(415) 323-9000		karish@forel.stanford.edu