On Mon, Feb 3, 2014 at 12:46 PM, Robert Elz wrote:
No, and I wasn't arguing against using mkstemps() where it is available,
just against using link() in preference to rename() - that one makes no
sense.
| "mkstemps() first appeared in OpenBSD 2.4".
Oh, OK, given all those systems, I guess it is about time for it to
migrate to NetBSD as well (it isn't there yet.)
Just a bit of history:
The whole rename of the temp file was introduced by me so the temp file
can have a proper suffix for cases when the data is provided to an
external process since it is common for programs to use filename
extension as how to process the data. I understood, at the time,
that rename() was atomic and relatively safe.
At the time, I only knew about mkstemp() [Notice there is no 's' at the
end of the function], therefore, there was no system call to make a
temporary file with a specific suffix. My older linux system I was
using at the time when making edits to nmh (and still have operational)
does not have the call. A later one I have running (CentOS 5) does have
it, but there is no manpage! I had to grep the system header files just
now to verify the later system had the call.
The DoS scenario David mentions seems highly unlikely to occur and it
does not concern me. But I am all in favor of using mkstemps() and I
would have used it if it widely available at the time. If it is not
available, mkstemp()/rename() should be the fallback. nmh should
have an abstract function that allows the creation of a temp file with
a suffix so it can hide the method used based on what the system
supports.
--ewh
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers