Subject: Re: CRITICAL ** Holes in default cron jobs ** CRITICAL
To: Matthew Jacob <firstname.lastname@example.org>
From: Warner Losh <email@example.com>
Date: 12/30/1996 14:54:07
In message <9612302025.AA03768@feral.com> Matthew Jacob writes:
: Perhaps I'm being obtuse but isn't what you want readily available
: via fstat? In fact, the lookup operation *is* separate from the open
Nope. Fstat only operates on the last element of the path, while this
attack relies on symbolic links inside of the path (eg /a/b/c where b
is the symlink).
The big problem is that this operation isn't atomic. In order to be
secure in all cases, you'd have to have /tmp in its own partition, and
then delete by inode. Or you need some way to close the window
between lookup and use. You may still have a race if you traverse
down into a tree in /tmp because you can get that yanked out from
under you if you aren't careful.
About the best you can hope for is to delete the files as you see them
in the tree, but even that has a small race in it should the process
that is doing that hits a snag.
The real problem is that /tmp wasn't designed to be secure. It was
designed to be convenient for people to dump stuff into....