Subject: Re: Permissions on directories.
To: John F. Woods <jfw@jfwhome.funhouse.com>
From: SAVE MY WALRUS <greywolf@starwolf.starwolf.com>
List: current-users
Date: 10/20/1998 20:55:46
"John F. Woods" sez:
/*
* > 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.)
You did; I lost the mail.
*
* (Geez, how many evil crocks have been added to BSD in its long and checkered
* history because of "academic environments"?)
Well, yeah, but considering that BSD _was_ an academic environment for
ever and a day...
* Note that in addition to the file permission bits, whose well-established
* meanings one probably ought not to mess with in imaginative ways
You mean like Solaris (and others) are doing now with non-executable files?
* ("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).)
Which is why I asked about it (I be obtuse, I be not stupid!). chflags()
seems a more reasonable interface for this sort of thing.
Technically, chflags() would be the more reasonable place for the behaviour
exhibited by the sticky bit, but the sticky bit got there before the
file flags did.
* 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.
I don't see _why_ it wouldn't be accepted; there are properties that
are handled by ftpd which should really be handled by the operating
system.
* 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...
Your point is well taken; I used /tmp because I've (used it/seen it used)
as a DoS point before.
/usr/tmp was another favourite to abuse, but only because we ran out of
space on /xa, /xb and /cs (our user partitions in days of yore).
*/
--*greywolf;
--
Q: Where are an elephant's sex organs?
A (rot13): Va uvf srrg. Vs ur fgrcf ba lbh, lbh'er shpxrq.