[Zope3-dev] RE: [Zope3-checkins] CVS: Zope3/lib/python/Zope/Configuration/tests - testXML.py:1.6

[Tim Peters]

[R. David Murray, on temp file code in testXML.py]
> My point in writing it the way I did originally, using
> NamedTemporaryFile if it existed (2.3) and a dummy class if it didn't
> (2.2) was to avoid the security warning running under 2.3.

Sure, that was clear.  Had you tried it on Win98, it would have worked, too.
On Win2K it didn't.

> Since mktemp is the thing that generates the security warning, this
> change means the security warning comes back.  (Not that you can tell;
> there are a bunch of tests that currently generate this warning
> running under 2.3).

My point in changing it was to get the test to run again on Win2K, not to
solve *all* the world's problems <wink>.

> So, what is the *correct* (secure) way to do temporary files
> cross-platform when you need to be able to open the file again by
> name after creating it?

I don't know if that's a use case that *can* be addressed in a x-platform
way.  The author of NamedTemporaryFile didn't write a test for it, so I
can't guess what he intended.  That it simply doesn't work x-platform
suggests it's going to be trouble, if it's important to do so.  These
"security warning" mktemp() nags are bothering test suites in lots of
projects, and I expect we'll eventually do something to address *that*
instead.

> (And yes, Tim, I realize that according to your previous email about
> cross platform issues the answer is "no" <grin>).
>
> Oh, yeah, and there aren't any notes in the docs of NamedTemporaryFile
> that say you *can't* open it twice on Windows.

Maybe there should be.  The author of this code didn't run on Windows at
all, and it's not actually a Win32 issue:  it's specific to WinNT and
beyond.  The first time I bumped into this (in a different context), it took
*hours* just to figure out why the program worked on Win98 but not Win2K.
Unfortunately, insight did not imply a cure:  deep in the bowels of
Microsoft's I/O implementation, specifiying O_TEMPORARY ends up fiddling
with other stuff such that a file opened that way can be opened again if and
only if subsequent attempts to open the file request and *get*
FILE_SHARE_DELETE access, a kind of permission that doesn't even exist on
Win9x, and for which there is no access via Microsoft's "standard C"
functions.  Worming around all that is a project, and one for which I can't
make time.

> And come to think of it, given the description of how it works under
> Unix (removing the directory entry as soon as it is created), how is
> it that my original code even worked on Unix?

NamedTemporaryFile doesn't unlink the file, so at the code level that's not
a mystery.  The doc's

    This function operates exactly as TemporaryFile does, except that
    the file is guaranteed to have a visible name in the file system.

seems accurate enough.  If you have to, pretend NamedTemporaryFile goes on
to link the file back into the filesystem again immediately after unlinking
it <wink>.

Bottom line:  NameTemporaryFile is a new-in-2.3 thing, written by a Linux
Guy with no visible x-platform experience, and what it actually does across
platforms is something we're *discovering* via poke-and-hope.  The
operations it uses aren't covered by the C standard, so there's no guessing
what it will do in advance if pushed beyond its most obvious use case
(create a temp file, use it, and don't get fancy).  Maybe it should do
better than that, but I don't even know how to make it do better than that
on Win2K.

Pretending it doesn't exist in fancy cases seems the most pragmatic
approach, and the mktemp() nags are a major PITA that won't survive.