On Thu, 26 Apr 2001 01:14:18 +0930, [EMAIL PROTECTED] said:
> I see your point about buffer overflows, but I'm not sure that the same
> applies to /tmp races: maybe I'm missing something, but my perception of the
> the essence of /tmp races is this: someone sticks a symlink in /tmp just
> before a privileged user (e.g. root) is about to create a file with that
> name. Privileged user doesn't check properly, and writes stuff to the
> file the non-privileged user selected.
Wasn't there a *LONG* thread a while ago about how to properly clean a /tmp
on a *secure* regular basis? (the problem being that a malicious user could
drop something into /tmp that ended up causing the /tmp cleaner to clean
the wrong thing....)
Remember - there's *two* race conditions - one for creating a file (causing
the victim to create a file other than where he thought), and one for
de-referencing a filename (causing the victim to read an existing file other
than the one he intended). /tmp cleaners are in the second category....
Of course, there's still people out there getting burnt by a simple
find /tmp -mtime -7 -type f | xargs rm
Lots of joy to be found here - (like this:
mkdir /tmp/foo\n; touch /tmp/foo\n/vmunix
Wait a week,and watch the next reboot fail. Note that *this* little
gem will work even with separate per-user /tmp directories - this is
why GNU find/xargs have a -0 option.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
PGP signature
