Subject: tmp issues: trap before making safe tmp and not defining directory
To: None <tech-security@netbsd.org>
From: Jeremy C. Reed <reed@reedmedia.net>
List: tech-security
Date: 10/31/2003 17:11:05
This isn't NetBSD specific (but does involve software in pkgsrc).
I have some questions I'd like comments on.
I have seen many scripts that set up tmp files with a trap before. This
sets up a trap to delete the directory before the directory is even
created. In a very rare condition, if signal 1 2 3 7 13 or 15 hits it then
the directory will be removed before even checked.
For example (not my code):
cleanup()
{
rc=$?
$needsCleanup && test -n "$tmpdir" && test -d "$tmpdir" \
&& { rm -f "$tmpdir"/*; cd /; rmdir "$tmpdir"; }
exit $rc
}
setupTmpDir()
{
$needsCleanup && return
trap 'cleanup' 1 2 3 7 13 15
needsCleanup=true
*** what if signal hits here, so trap does cleanup on tmpdir which was
symlinked to your important files ***
(umask 077; mkdir "$tmpdir") \
|| abort "could not create directory \`$tmpdir'"
}
...
tmpdir=${TMP-/tmp}/$progname.$$
setupTmpDir
cd "$tmpdir" || {
false # some systems need this to set nonzero $?
cleanup
}
Maybe that doesn't matter because a user who could make the tmp symlinks
may not be able to force the signals to that script. What do you think?
I think the shell traps should be setup after just in case of some
random event. Or does it not matter?
Also, I have seen several scripts that use tempfiles like abc.$$ but are
used under some non-world-writable directory. This is usually okay and
common. But some scripts may create the the full temp file name based on a
command-line argument or the path/to/executable.
Due to poor judgment or accidently wrong usage the script with base temp
file usage could be used in a directory (or reference a directory) that is
writable by others.
I believe that all temp file usage should use safe temp file creation if
the possible location is not forced. What do you think?
Any good documents about the above? (That I could use as references if I
choose to report these.)
Jeremy C. Reed
http://bsd.reedmedia.net/