Subject: Re: Permissions on directories.
To: John F. Woods <firstname.lastname@example.org>
From: Brian Buhrow <email@example.com>
Date: 10/20/1998 13:40:38
Personally, I don't know why one would want to prevent someone from
making directories below a certain point in the filesystem tree while
allowing them to create files. If the issue is one of how to delete
subdirectories in a timely fashion, there are ways around that. I, for
one, would consider that an imposing restriction for shell users.
On Oct 20, 3:11pm, "John F. Woods" wrote:
} Subject: Re: Permissions on directories.
} > 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...
>-- End of excerpt from "John F. Woods"