Subject: sticky bit dir semantics and giving away unlink perms
To: None <tech-kern@NetBSD.ORG>
From: VaX#n8 <firstname.lastname@example.org>
Date: 08/08/1996 00:19:22
With the current sticky-bit semantics on directories, it is not easy to
allow someone else to remove your files from, say, /tmp.
Solaris 2.4+ (I think) has a fourth check when deciding access to unlink
a file from a sticky-bitted directory; if the user has write access to the
file, [s]he may unlink it.
I am not sure if this subsumes the other 2 criteria (the user is the super-user,
user owns the parent directory) or not. I think it may. It _could_ subsume
the (user is the owner) criterion, with only a mild change in semantics. I've
personally never created a file in a sticky-dir without user-write perms. :)
This is primarily useful in very open environments where everyone has a
umask of 002 and belongs to one group; misbehaving or aborting programs
may leave a temp file in /tmp with a common name, and you are forced to
hunt down the owner or the superuser before you can run your program,
which is a pain.
How about it, science? :)