Subject: Re: Permissions on directories.
To: Todd Vierling <email@example.com>
From: I can teach you how to fish... <firstname.lastname@example.org>
Date: 10/20/1998 10:58:42
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
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 email@example.com; Bus. firstname.lastname@example.org)
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