[Nmh-workers] thoughts on tmp*

[Lyndon Nerenberg]

A few comments from the peanut gallery ...

1) Any attempt at a portable programmatic method of dealing with  
scratch files is doomed from the outset.

2) Hardwiring ~/Mail is as bad as wiring /tmp. Worse, in fact. The  
purpose of /tmp is to host a portion of the file system that's *fast*.  
Home directories have a tendency towards being mounted from network  
servers, the underlying RTT-based latency being counter to the purpose  
of /tmp. That MH wants these files to be long-lived is a separate  
issue of misuse.

3) Any scheme to specify the location of scratch files must follow the  
long-standing ${TMPDIR} convention.

The only sane solution to this problem is to build an internal version  
of mkstemp() that acts like this:

  tmp = NULL;
  tmp = mhgetvar("tmpdir");
  if (tmp == NULL) {
    tmp = getenv("TMPDIR");
  }
  if (tmp == NULL) {
    tmp = "/tmp";
  }
  /* do mkstemp-like file creation behavior */

but with modifications to accommodate the mis-behavior that wants the  
files to stick around.

This business of passing state around through scratch files needs to  
be examined. State-passing is a distinct operation from storing  
scratch data, and this makes me think there's a need to examine  
everything that uses "/tmp" currently to disambiguate the two. My gut  
feeling is that isolating the two operations will make it clear what  
can be handled by mktemp() and friends vs. what needs to be  
incorporated into the existing state tracking mechanism (such as it is).

And in the short term, the immediate issue with securing scratch files  
is best dealt with by incorporating a portable version of mkstemp()  
into the source tree that uses an implied sub-directory for its files.  
E.g.:

        int foo = nmhtmp("mumbleXXXXX", 0);

would create (in the default case) ${tmp}/nmh-1001/mumble10546-1 based  
on the invokers real uid being 1001, a pid of 10546, and this being  
iteration 1. The routine creates nmh-1001 mode 700. tmp is evaluated  
as per my pseudo-code above. If the second argument is non-zero, the  
file is unlinked after the open. (Add a third argument if you need the  
actual filename returned.)

--lyndon