[patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath

[Marcus Brinkmann]

At Thu, 25 May 2006 01:21:36 +0100,
"Israel G. Lugo" <ilugo at bridonsecurity.com> wrote:
> > Give me a number and I'll raise the size, but layers of fallbacks
> > strikes me as unnecessary complication in a relatively unimportant
> > place in the code.
> Why have a number at all? The solution I had proposed would have dealt
> with any size in an efficient manner, without wasting memory
> allocating 1,000,000 bytes "just to be sure" or failing because "42 is
> more than enough for anyone".

This is a bit beside the point, but I feel qualified to comment on
this, due to my experience with OS design, in particular the GNU/Hurd,
which does not define PATH_MAX or other constants like that.

The discussion is actually quite involved.  However, there are a
couple of notes that can be easily seen: First, no operating system
can allow arbitrary long string transfers in a single operation, be it
a kernel system call or an IPC string transfer between two user space
programs.  The reason is that it is a good idea to arrange everything
so that all kernel operations are bounded in time, and the bound
should be reasonably small (ie, not scale with the amount of available
memory, which in a persistent system may be as much as the total disk
memory available, ie Terabytes).

Although in theory you can build protocols where a string is
transfered piece-wise in more than one operation, the same argument as
above prevents us from using such protocols in the kernels or servers
that provide services to potentially non-cooperating clients.  This
effectively limits at least the size of NAME_MAX, which is a pathname
component.

Even in Unixes with a fixed PATH_MAX you can make use of longer path
names by repeatedly "cd'ing" into directories.  This is an
idiosyncratic inconsistency that can lead to subtle problems all over
the place.  You know have nameable resources whose complete names are
invalid.  This should make us suspicious about the wisdom in such a
feature.

From the perspective of an application, if you want to allow arbitrary
long pathnames or not is a question that has no universal answer.  It
depends, for example, on which agent provides the name to which other
agent, and what the relationship between these agents is.  Just as a
trivial example, you do not want to accept arbitrary long pathnames in
the query interface of an HTTP server on a public network.  Similar
situations can arise locally.

I have supported arbitrary long path names in the past, but in the
light of that experience and the above analysis I am somewhat backing
off.  In the presence of always unbounded sizes, you lose some of the
ability to reason about the dynamic properties of the system.  On the
other hand, in support of your argument, _arbitrary_ limits on
pathnames are bound to cause spurious failures as well.

Any real system will impose some sort of limits of some sort, at
various levels (storage, communication, application), which may be
dynamic.  So, I think that in the end, the choice between fixed
constant size and unbounded size is incomplete: The right answer is in
the middle: A bounded size which is dynamically determined.  This
however requires more theory on operation than we have to our support
in existing legacy operating systems, so a compromise is necessary.

Thanks,
Marcus