[alexandria-devel] Proposed addition of temporary file creation utilities

[Pascal J. Bourguignon]

Hans Hübner <hans.huebner at 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.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.