Re: LYNX-DEV fix-v2 temp code.

[Klaus Weide]

On Wed, 16 Jul 1997, Jonathan Sergent wrote:

> Anyone willing to look at it?

I did (again), but not very carefully.  Would prefer that I not be
the only one who looks at it.  There seemed to be other people with
interest (and strong opinions) on this on the list, a while ago.

> The current FOTEMODS code doesn't avoid the race condition problem (it
> is possible to create the symlink to the existing file after tempname()
> but before the fopen to write on the file with another process.  It's
> hard to get in there at the right time, but it's not impossible.)  And 
> although it can avoid (but not prevent if it loses the race) overwriting
> existing files through symlinks it does nothing about not creating new
> files (through symlinks which don't point to existing files).  Having to
> use "/tmp/$USER" directories is annoying.
> 
> I really think we should seriously consider trying to get rid of those 
> problems.  If you folks don't believe me on either of the above points 
> I can put together a demonstration script of some sort but I'd rather 
> not do that for hopefully obvious reasons.

I agree that with the previous (Fote's) code there seems to be still a
small (but not zero-length) time between the checking and the opening
where an attack could succeed.  And you are tryin to fix that.

Your last fix has problems:

First, a minor annoyance, some compiler warnings:

gcc -g -DUNIX -DSVR4 -DSOLARIS2  -DUSE_SLANG -DCURS_PERFORMANCE 
-DUTMPX_FOR_UTMP -DUSE_DIRENT \
  -DLOCALE -DHAVE_TERMIOS_H  -I../WWW/Library/Implementation
-DDIRED_SUPPORT  -DOK_TAR -DOK_ZIP -DOK_GZIP -DOK_UUDECODE -DOK_OVERRIDE 
-DOK_PERMIT \
 -DCHECK_TEMP_SPACE -DSHELL_FILTERS -DEXP_CHARTRANS  -I..
-c HTFWriter.c -o HTFWriter.o
HTFWriter.c: In function `HTSaveAndExecute':
HTFWriter.c:467: warning: passing arg 3 of `_tempname' discards `const' from 
pointer target type
HTFWriter.c: In function `HTSaveToFile':
HTFWriter.c:636: warning: passing arg 3 of `_tempname' discards `const' from 
pointer target type


Next, a core dump.  It happens after doing exactly one action that would
create a temp file (for example, '=' or HISTORY), on quitting (in a
situation where the TEMP_SPACE in effect is regarded as insecure):

(gdb) where
#0  0xef6a1838 in _kill ()
#1  0xef66d7f4 in abort ()
#2  0x416d4 in FatalProblem (sig=11) at LYMain.c:2537
#3  <signal handler called>
#4  blank_line (p=0xb, n=0, ch=88 'X') at 
/opt/src/misc/slang/slang/src/slsmg.c:66
#5  0x58da8 in statusline (
    text=0xfb7a8 "*** ALERT *** Dangerous temp space!  See your 
administrator.") at LYUtils.c:1874
#6  0x5d000 in _tempname (namebuffer=0xeffff508 "\221`", action=1, 
extension=0xfb800 ".html",
    file=0xf2d20 "LYClean.c", line=129) at LYUtils.c:3225
#7  0x1be08 in cleanup_files () at LYClean.c:129
#8  0x1beec in cleanup () at LYClean.c:162
#9  0x3e8ec in main (argc=3, argv=0xeffffcac) at LYMain.c:1482
(gdb)

Observations:

1.) The annoy-message "*** ALERT *** Dangerous temp space!  See your
administrator." doesn't appear when it should, on the first attempt
to create a temp file, but is delayed.  It appears on the second attempt
(when another temp file is requested).  If the second attempt never
happens before quitting, there's the core dump.

2.) Should tempname do any warning message when it is called for
*cleanup*?  (as in the case above)

3.) The more direct cause of the core dump seems to be the use of
statusline() while LYCursesON is FALSE.  I am not sure what the best
way is for warning messages which may occur with LYCursesON TRUE or FALSE.
There doesn't seem to be one function that is designed for both cases.
So I guess you have to test for it.  See the code which generates the
"guessing..." messages in LYUtils.c for example.

Your turn...

    Klaus

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