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

[Klaus Weide]

On Fri, 9 May 1997, Jonathan Sergent wrote:

> In my opinion:
> 
> We want lynx to work as well (this includes "in a relatively secure
> fashion") in as many environments as possible.  "We" do this by 
> creating our temporary files with something like mkstemp.

Here is my attempt at it, as patches against official 2.7.1:

    <URL:http://sol.slcc.edu/lynx/klaus/temp/diffs-2.7.1--stemp.pch>

   (Visit <URL:http://sol.slcc.edu/lynx/klaus/temp/>, 
    then D)ownload, not P)rint, for a usable diff)

- Uses mkstemp() and does not overwrite temp files for re-use, if compiled
  with -DDONT_REUSE_TEMPFILES and -DUSE_MKSTEMP
- Exceptions: some cases where files are opend with "a" to append
  something (signature files), as well as where an external program is
  called on a temp file (EDITOR for mail etc. - what they do is not under
  the control of Lynx), as well as everything I have missed...
- Files are typically opened for writing, then closed, then opened for
  reading.  So it is still possible (if outside protections don't prevent
  it) to sneak a different file in _for reading_.
- No attempt is made to do anything about checking the directory,
  checking permissions, creating a directory, and so on - all the stuff
  that has been discussed.  I leave that to others better qualified...
- No attempt to use something else than mkstemp().
- Not much testing.
- Doesn't cover all temp files for VMS (some were created without
  using tempname(), and there is other special code).
- THIS CHANGES THE USER-VISIBLE BEHAVIOR OF LYNX.
  Whether this is acceptable or completely unacceptable, or even an
  improvement in some respect, I don't know and don't want to decide.  
  Instead of (a maximum of) exactly one 'l'ist screen (for example),
  there can now be many if one repeatedly does 'l', then follow some
  links, then 'l' again, follow more links...  Going back in history
  (PREV_DOC) takes one back through those, in the reverse order they
  were first created, as expected.  (Do some experiments to compare
  with normal Lynx behavior if this is unclear.)  Similar for other
  screens which are created as temp files.  BUT to avoid unlimited 
  growth of the number of temp files created in a session there is a
  maximum on the total number in this code (I have set it to
  #define MAX_TEMP_TOTAL 20 in userdefs.h).  Older temp files get
  automatically removed when that is reached.  That results in
  COULD_NOT_ACCESS_FILE messages when going back through the history,
  if a page backed by a temp file isn't there any more (neither in
  memory cache nor as a file).
  OTOH it MAY be a positive effect that the number of temp files kept 
  from file downloads during a session is also limited by this.

In summary, it should be clear that this isn't the solution to all the
problems mentioned (of which I am losing track anyway...).  It is more
of an attempt to explore what "using mkstemp" would actually mean.
The result is working code (as far as I have tested), but working
somewhat differently.  There may be much better approaches.

    Klaus

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