OS.FileSys.tmpName should create a temporary file, not just name it

[Munksgaard]

According to the documentation for OS.FileSys.tmpName, it should create a new temporary file:

This creates a new empty file with a unique name and returns the full pathname of the file. The named file will be readable and writable by the creating process, but, if the host operating systems supports it, not accessible by other users. This function can be used to create a temporary file that will not collide with other applications.

From: http://sml-family.org/Basis/os-file-sys.html#SIG:OS_FILE_SYS.tmpName:VAL

It seems like we are using tmpnam(3), which is deprecated, exactly because it doesn't actually create the file, but merely returns a suitable filename for a temporary file. This could lead to security issues.

Since August, SML/NJ uses mkstemp (at least on newer systems where it is supported) such that a file is actually created.

SML/NJ implementation: http://smlnj-gforge.cs.uchicago.edu/scm/viewvc.php/sml/trunk/runtime/c-libs/posix-os/tmpname.c?view=markup&root=smlnj

[Munksgaard]

A small comment on the basis library specification: It actually says that the file should be inaccessible to other users. One obvious way to do this would be to create the temporary file, and return some kind of file handle to the file instead of the file itself. However, we are required to return the filename itself, but creating the temporary file and returning the filename while keeping the file handle open wont work.

SML/NJ uses mkstemp, but closes the resulting file handle and returns the filename. In effect, the security issues that were the reason for deprecating tmpnam are still present; other processes can potentially access the temporary file in between the call to tmpName and actually opening the file.