Messages in this thread |  | | | From | Chuck Phillips <> | | Date | Sun, 24 Oct 1999 19:16:03 -0600 (MDT) | | Subject | Re: buglet in ext2 sticky bit? |
| |
From: Eilert Brinkmann <eilert@informatik.uni-bremen.de> > This is a difference, but not a bug in Solaris. It is documented in > the Solaris man page for chmod(2): > > If a directory is writable and has S_ISVTX (the sticky bit) > set, files within that directory can be removed or renamed > only if one or more of the following is true (see unlink(2) > and rename(2)): > o the user owns the file > o the user owns the directory > o the file is writable by the user > o the user is a privileged user
Excellent observation. This is almost exactly the wording used in the original SVr4 chmod(2) man page from 1990. Both POSIX96 and the original OSF documentation appear to be silent on the issue. Unfortunately, I don't have a copy of the XPG documentation to check. Although it isn't explicit, I believe the above behavior only applies *after* the normal permission checks grant delete permission.
FWIW, I believe the third bullet in particular (currently missing from Linux) makes the feature a *lot* more useful. Having the sticky bit tie delete permissions to write permissions allows processes with different UIDs to use /tmp and /var/tmp with more overall security. Think of cooperating processes where not all of them actually need a particular UID or a privileged UID. In this case, SVr4 "sticky dir" semantics allow/encourage least-privilege design. Linux semantics currently don't.
If you already can write to a file, being able to actually delete it isn't likely to create an *additional* security hole. Exception: If the file's existence is used merely as a semaphore and the contents ignored -- but then there is the obvious possibility of not making the file writable by the world when it is created.
Best Regards, Chuck
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |