[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nmh-workers] thoughts on tmp*

From: Lyndon Nerenberg
Subject: [Nmh-workers] thoughts on tmp*
Date: Sun, 6 Apr 2008 00:38:46 -0700

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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]