You might check out how the CGI module implements temp-files. It takes things a step further and unlinks the file after an open() wich makes it harder for another process to intercept the file handle.

But that's exactly what open my $fh, "+>", undef does. (Under osen that permit it.)

stout:~ [16:28:32]$ strace -eopen,unlink perl -e 'open $f, "+>", undef
+'
open("/etc/ld.so.preload", O_RDONLY)    = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libnsl.so.1", O_RDONLY)      = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/lib/libm.so.6", O_RDONLY)        = 3
open("/lib/libcrypt.so.1", O_RDONLY)    = 3
open("/lib/libutil.so.1", O_RDONLY)     = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 3
open("/dev/null", O_RDONLY|O_LARGEFILE) = 3
open("/tmp/PerlIO_dr5fu4", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 
+3
unlink("/tmp/PerlIO_dr5fu4")            = 0
Process 17389 detached
[download]

Also see:

stout:~ [16:29:17]$ perl -le 'open $f, "+>", undef; system "ls -l /pro
+c/$$/fd"'
total 5
lrwx------ 1 blazar users 64 Dec  6 16:29 0 -> /dev/pts/0
lrwx------ 1 blazar users 64 Dec  6 16:29 1 -> /dev/pts/0
lrwx------ 1 blazar users 64 Dec  6 16:29 2 -> /dev/pts/0
lrwx------ 1 blazar users 64 Dec  6 16:29 3 -> /tmp/.nfs00364089000002
+21
lr-x------ 1 blazar users 64 Dec  6 16:29 4 -> pipe:[12410097]
[download]

(That's because /tmp is nfs mounted here, under other fs's it would explicitly tell you it has been deleted - at least IIRC it did when I tried it.)