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/