On Thu, 26 Apr 2001 01:14:18 +0930, matthewat_private 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
This archive was generated by hypermail 2b30 : Wed Apr 25 2001 - 22:04:07 PDT