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

(Note that I did confirm that CAP (mis)uses the setuid bit on directories.)

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

(Geez, how many evil crocks have been added to BSD in its long and checkered
history because of "academic environments"?)

Note that in addition to the file permission bits, whose well-established
meanings one probably ought not to mess with in imaginative ways ("the
setuid bit on non-owner-executable directories who group-id's high-order bit
is set means........"), there are also (now) 32 file "flags", only seven of
which are currently in use.  (See chflags(1).)

I'd kind of like to see some of these flag bits permanently reserved
for site-local extensions; i.e. if the no-subdirectories property
isn't accepted, you could implement it locally and feel confident that
you'll never have that bit re-used in NetBSD 2.9...  as long as you
don't have more than (say) 8 local extensions.

Of course, you realize that the instant you install a "no
subdirectories in /tmp" feature, someone will complain that they have
an archive with a dozen or so small files that they can't unpack in
/tmp because it's structured in directories...  Hmm, I think at least
some versions of Netscape have dropped zip files in /tmp for java
applets; I wonder if Netscape ever wants to create temporary
directories for those applets...