Todd Vierling sez:
/*
 * ...Yet BSD gives the "setgid" behavior _all_ the time.  I'd certainly perfer
 * this to be an option, as SVR4's method of using the real user's gid sounds
 * more sane to me.

The ability to have it optional certainly is more appealing; SVRx (for
0 <= x < 4) only did the real gid, while BSD has _always_ done the
"inherit the parent directory's gid" which, while I was used to it,
was occasionally annoying.

It was especially fun when I actually managed to chmod a file setgid
for a group of which I was not a member (buggy implementation, but
still...).  Sun was the first to actually do something sane with the
setgid bit.

You know, I asked about the setuid bit on a directory, and got someone
telling me to man sticky(8).  There IS a difference between (mode|04000)
and (mode|01000), somewhere in the neighborhood of 768.

I always wondered why the sticky bit on a directory got the properties
which should have been assigned to the setuid bit.

...which still leaves the proposal danced around with a wide berth:

How about some way to inhibit the creation of directories beneath a
directory while still allowing file creation?  Especially in an
academic environment, this would be handy, if for no other reason than
to circumvent DoS attacks on, say /tmp.  Policies are all well and good,
but quotas on /tmp are not reasonable (especially during a particularly
large compile session), and under mfs I'm not sure they're enforceable
anyway (but only because I haven't tried).  There needs to be a
system mechanism in place to allow such controls.

 * 
 * -- 
 * -- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)
 * 
 */





				--*greywolf;
--
There is nothing so phenomenal as the music of the Grateful Dead.  ___
No other music can so instantly bring a smile to one's face as    / / \
that of the Dead.  The tape goes in, the smile goes on.           \_7_/
		- Thank you, Jerry! -                              O_O
                                                                   |||