tmp issues: trap before making safe tmp and no change directory

["Jeremy C. Reed" <reed@xxxxxxxxxxxxx>]

I am working on updating tetex2-bin for a packages collection (pkgsrc). I
already reported one tmp unsafe issue in xdvizilla that has been fixed in
xdvi/xdvik/texk/xdvik CVS (hopefully that covers tetex-src too).

Anyways, I had 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 hit it then
the directory will be removed before even checked.

For example:

  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.)


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 tmp 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 tmp file usage could be used
in a directory (or reference a directory) that is world-writable.

I believe that all tmp$$ style usage should use safe tmp 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/

------------------------------------------------------------------------
     To unsubscribe email security-discuss-request@xxxxxxxxxxxxxxxxx
         with "unsubscribe" in the subject of the message.