lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV Re: ...vulnerability in Lynx...


From: Klaus Weide
Subject: Re: LYNX-DEV Re: ...vulnerability in Lynx...
Date: Wed, 7 May 1997 22:00:26 -0500 (CDT)

On Wed, 7 May 1997, Scott McGee (Personal) wrote:

> Klaus Weide <address@hidden> writes:
> >
> >On Wed, 7 May 1997, Scott McGee (Personal) wrote:
> >
> >> OK, let me jump into to forray here.
> >> 
> >> How about doing the following:
> >> 
> >> define a symbol (has_mkstemp) based on the availiblity of this function
> >> use code like this
[ snip ]
> >This doesn't seem to adapt well to the way Lynx uses many of its
> >temporary files.  Files are created and written and closed; then opened
> >for reading in totally different modules.
> >
> >The different modules pass the file only as a filename (or URL) between
> >each other, not as a (FILE *).
> >
> >Also some things require the temp file to have a specific ending (like
> >".html" or ".txt") to work correctly.  Soemthing mkstemp() cannot do,
> >since it wants to modify the *last* six filename characters.
> 
> Hmm, ok, modify the above to close the (as yet) empty file, leaving a file
> with the generated name and our permissions set so others don't mess with it,

But that relies on (a) the directory not being writable to others, or 
(b) the sticky bit being set.  Otherwise others can still mess with the
file - right?  In case (a) there isn't a problem anyway (assuming the
directory itself cannot be moved).  In case (b) something like my wrapper
script should be sufficient.

> and then pass the file name. You can even rename it to add any desired 
> extensions after creating and closing it (have to watch for existing files
> when doing the rename, but that's not too hard).
[...]
 
> Well..., is the creation of temp files delegated to one function, or scattered
> all over the code? I can take a look and see about doing it. Maybe even
> download the freeBSD code and implement it for Lynx. I'll have a look see.

Generation of the *name* is delegated to one function, Lynx's own
tempname(), in LYUtils.c, but the caller of that function is keeping track
of everything else, including adapting the name with a suffix, and
possibly storing the name to write to it again.  I count 21 uses of
tempname() in 13 files.

Well it's not as much as modifying all TRACE fprint's in all
source files...

The by far simplest thing is to give Lynx a private space to play around
in as it likes.  But we cannot just change the default in userdefs.h
from "/tmp/" to "~/.lynx/" and expect all users (or admins) to create
those dirs before Lynx can work.  Lynx could create a subdirectory itself,
but then there are some other questions - should they be per-process?
Should they be removed completely when Lynx exits?  What should happen if
such a dir already exists and contains other files, or is a symlink (to
/tmp/, for example :) ) which may be legitimate?

   Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

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