Hans Hübner hans.huebner@gmail.com writes:
Faré,
neither iolib nor osicat are the right place for temporary file handling operators like the one I proposed. Both these libraries are specifically targeted towards POSIX systems, so there is no chance that they will cooperate, say, with ABCL.
A lot of systems implement the POSIX API. http://en.wikipedia.org/wiki/POSIX
Does the JVM run on a non-POSIX plateform? Does it not provide the mkstemp(3) POSIX function?
Setting the process umask is something that is completely unrelated to portably creating temporary files.
You mean to say that (CL) portably creating temporary files cannot be done controling the umask, because there's no such notion in CL.
That's all right, and for a lot of uses, this may be OK, but that doesn't fulfill the need for a mkstemp() when the security consideration need to be taken into account, ie. as soon as you're writing a real program.
Ie. there's no point in providing a conforming temporary file creation, for real stuff you need a portability temporary file creation library that allows the setting of umask.
If this is not going into Alexandria, there are two likely other outcomes: Either the code goes into Postmodern, giving the next person the same problem (and I've not had this problem once, but many times), or it will end up in a trivial-temporary-file library that may include some conditional code for setting up the default temporary directory in a meaningful way. With Quicklisp, this would not hurt much, but it certainly feels a little silly to additional trivial-whatever libraries for basic functionality.
You're discovering that creation of temporary files is not so trivial after all. On unix, this has a long history of tries and failures. To wit:
mktemp(3)
BUGS
Never use mktemp(). Some implementations follow 4.3BSD and replace XXXXXX by the current process ID and a single letter, so that at most 26 different names can be returned. Since on the one hand the names are easy to guess, and on the other hand there is a race between testing whether the name exists and opening the file, every use of mktemp() is a security risk. The race is avoided by mkstemp(3).
tempnam(3)
NOTES
Although tempnam() generates names that are difficult to guess, it is nevertheless possible that between the time that tempnam() returns a pathname, and the time that the program opens it, another program might create that pathname using open(2), or create it as a symbolic link. This can lead to security holes. To avoid such possi‐ bilities, use the open(2) O_EXCL flag to open the pathname. Or better yet, use mkstemp(3) or tmpfile(3).
SUSv2 does not mention the use of TMPDIR; glibc will use it only when the program is not set-user-ID. On SVr4, the directory used under d) is /tmp (and this is what glibc does).
Because it dynamically allocates memory used to return the pathname, tempnam() is reentrant, and thus thread safe, unlike tmpnam(3).
The tempnam() function generates a different string each time it is called, up to TMP_MAX (defined in <stdio.h>) times. If it is called more than TMP_MAX times, the behavior is implementation defined.
tempnam() uses at most the first five bytes from pfx.
The glibc implementation of tempnam() will fail with the error EEXIST upon failure to find a unique name.
BUGS
The precise meaning of "appropriate" is undefined; it is unspecified how accessibil‐ ity of a directory is determined.
Never use this function. Use mkstemp(3) or tmpfile(3) instead.
mkstemp(3)
NOTES
The old behavior of creating a file with mode 0666 may be a security risk, especially since other UNIX flavors use 0600, and somebody might overlook this detail when porting pro‐ grams.
More generally, the POSIX specification of mkstemp() does not say anything about file modes, so the application should make sure its file mode creation mask (see umask(2)) is set appropriately before calling mkstemp() (and mkostemp()).
So it's not the first time that such difficulties are identified in an apparently simple API.
Again, for a toy, just creating a randomly named file is ok. But in production code you will need more than that.
Your remarks regarding how this request represents a "poor way to promote Lisp as a serious language" are unwelcome, unconstructive and wrong. Thank you for not continuing on that path.
That's a little strong.