Re: lynx-dev Lynx 2.8.3 with nmh problems

[Klaus Weide]

[ Leaving out some stuff about specific code - need to look more ]

On Mon, 8 May 100, T.E.Dickey wrote:

> The people who were criticizing the temp-file manipulation only had to
> point out the problems in making reopening a temp-file to make their point.

I don't know who "the people who ..." are.  I am fairly sure that they
haven't done anything like pointing out the problems on this list.
So I still don't know what that point is.

(I don't recognize any of the bugtraq reports I know of as fitting
your description.)


> > Well, not on this machine.  Not in most sane environments, right? 
> 
> older machines (lynx users seem to favor those ;-)

Well, age of the "machine" (hardware) doesn't really matter.  Age of
the OS may.  I don't know that lynx users favor such old OSs, especially
given linux's popularity.


> > The stat is from mktemp().  It doesn't "touch" the filesystem in the 
> > sense of writing anything, but it has to check whether a file exists. 
> 
> yes - so there's a race there.
> but the return value of mkdir should be sufficient to verify that.

Yes.  But if the mkdir fails, lynx exits (rather than allowing to continue
and just lettting actual temp file operations fail).


> > Can you see why I don't want this code, or want a way to suppress it? 
> 
> no - it's simple to set $TMPDIR to a directory which satisfies lynx,
> even one which you create yourself under /tmp.

That argument cuts both ways.  Actually, more the other way.
It's always been possible to set $TMPDIR or $LYNX_TEMP_SPACE to do
that.  If everyone were doing it, there wouldn't be any problem, and
we wouldn't have any of these discussions, and "the people who ..."
wouldn't have anything to criticize.

To enumerate reasons "why I don't want":
 1. added complications (e.g., umask problem)
 2. added opportunity for somone to interfere with my process (make
    lynx exit with error - see above)
 3. added overhead of creating/removing a directory - completely
    unnecessary in many situations (e.g. with -dump, -source)
 4. added chance of leaving stray directories (if lynx crashes, or
    system crashes).
 5. It isn't easy to see whether such a directory belongs to a still-
    running process or is old garbage.
 6. Currently impossible to run lynx (if compiled with HAVE_MKTEMP)
    without a writable directory (which you agreed should be accomodated,
    below)
 7. It's undocumented that lynx now sometimes acts this way, sometimes
    not, and what the criteria are.

> > After all, I might be running lynx with -dump or -source, from a cron 
> > job or cgi script etc., such that no temp file will ever be generated. 
> 
> ok - that's a reasonable qualification which we should accommodate
> (but of course with file-caching, that's not true, right?).


> > So if I understand you right, stuff added in LYMain.c (subdir creation) 
> > doesn't make the stuff in LYUtils.c any less necessary.  That's basically 
> 
> there's some overlap in coverage.  doesn't cover download/print operations,
> which was iirc the original motivation for the logic in IsOurFile.

There isn't anything special about temporary files used for download or print
AFAICS.

> -- look on the bright side: the 2.8.3 release is not marked "FORBIDDEN"
>    in FreeBSD any more.

I don't know that it ever was marked "FORBIDDEN", whatever that means.

If it's now more acceptable to those folks, I assume that's because
of the fixed buffer overrun.  If you know differently, maybe from
disscussion with their "security officer", please share your information
with the list.

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden