On February 2, 2010 at 22:26, Peter Maydell wrote:
Yes, this is why it's difficult to fix :-). Unfortunately, if you
use mkstemp() but still allow the rest of the code to reopen
the temporary file by name, you've shut the linker up but
not completely closed the security hole. See
http://www.mail-archive.com/nmh-workers(_at_)nongnu(_dot_)org/msg01380.html
So I would vote against (the tempfile related parts of) this patch.
I do not think the problem applies here. With mkstemp(), the
file is actually created at the time, so no race condition.
If you look at the new functions, if no fd and no FILE return
is requested, I only close the file. I do NOT unlink it.
There are parts of the code where the file "sits" there before
it is opened, but in that case, it is actually re-opening an
existing file vs creating a new file.
The only way the file becomes a vulnerability is of the sys admin
has misconfigured the tmp directory to allow anyone to clobber
anyone elses file.
As for temporary files under ~/Mail, some operations in the
code do that since the files end up being renamed. It
is possible to modify the new functions I've added to default
to the user's mail directory for creating temporary files
vs /tmp.
--ewh
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers