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