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/