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

Guy Harris guy at auspex.auspex.com
Tue Oct 24 05:56:07 AEST 1989


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

Yes, unfortunately older UNIX systems and systems have haven't picked up
"id" don't have it....

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

At least in the first case, the SunOS "chmod" has been changed; to quote
the 4.0.3 CHMOD(1V)

  Absolute Modes
     An absolute mode is an octal number constructed from the  OR
     of the following modes:

	...

     2000    Set group ID on execution (this bit  is  ignored  if
             the  file  is  a directory; it may be set or cleared
             only using symbolic mode).

so "chmod 775 dirname" would preserve the setting of the set-GID bit.

As for the second case, I almost never forcibly set modes with "chmod";
I usually turn them on and off with "+" and "-", so that's not a
problem.  If you want to do the moral equivalent of "chmod 775"
symbolically - i.e., leave the set-GID bit alone, but force the
directory to have owner and group read/write/execute and other
read/execute permission, you can do

	chmod ug+rwx,o-w,o+rx dirname

>How else could this be handled?
>
>    - Pick one of the two styles, maybe on a per-host basis, and stick to it.

SunOS does have a "grpid" mount-time flag that forces the 4.[23]BSD semantics
for all directories on that file system, regardless of the state of the
set-GID bit.



More information about the Comp.unix.wizards mailing list