Bug 89967 - lynx hangs on operation when lynx_temp_space contains directory which is link
Summary: lynx hangs on operation when lynx_temp_space contains directory which is link
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lynx
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-30 14:06 UTC by Sysoltsev Slawa
Modified: 2007-04-18 16:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-05-21 11:28:31 UTC
Embargoed:


Attachments (Terms of Use)

Description Sysoltsev Slawa 2003-04-30 14:06:15 UTC
Description of problem:
From some time I noticed that lynx just hangs on system I use. It hangs and 
produces temporary *.html files in my tmp directory with impressive speed. I get to 
debug it and I found an issue that causes lynx to enter an infinite loop.
The infinite cycle is in LYOpenTemp function (cycle is LYUtils.c:5868 - 
LYUtils.c:5895). There is an attempt to create temporary file, for 
example â/users/vsysoltx/lynx-tmp/w7Hvle.htmlâ. For opening file it enters 
LYNewTxtFile (LYUtils.c:5715) and further in OpenHiddenFile (LYUtils.c:5645). 
Ok, further, mode = âwâ, try to open file through open(â/users/vsysoltx/lynx-
tmp/w7Hvle.htmlâ, O_CREAT|O_EXCL|O_WRONLY, HIDE_CHMOD) follows, 
but âopenâ returns EEXIST because file is already opened! It was opened during 
call from LYOpenTemp to fmt_tempname and there mkstemp opened file.
But OK, if you are going to open it twice, it is your wish maybe. Letâs return back 
to OpenHiddenFile. âopenâ returns EEXIST, fd = -1, program think that something 
wrong. There is comment in LYUtils.c :5662 about some race etc, so just created 
temporary file is deleted and created again .. but only if IsOurFile(name) returns 
TRUE. And IsOurFile(name) returns true only if there is no directory that is link in 
full temporary file name (there is scrupulous check in IsOurFile where leafs from 
path are cut and the rest is checked against being a symbolic link). Ha, but I have 
home directory being a hard link! So if I have TMPDIR pointing to somewhere in 
my home directory IsOurFile(name) returns false. That causes OpenHiddenFile to 
return fp = 0, further LYNewTxtFile returns fp = 0 and we get again in our infinite 
cycle in LYUtils.c:5868 - LYUtils.c:5895. As only result new temporary file is 
generated.

The solution I think in remembering that mkstemp generates temporary file and 
you do not need to create it again. But even if you wanted to ensure that 
temporary file wouldnât contain directories that are links, you should do it before 
file creation and emit fatal error in unsatisfactory case. Hang mustnât occur, 
moreover filesystem become very busy spawning temporary files with great speed; 
that might be a security issue.

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
Be in empty directory, I assume that $TMPDIR is your real tmp dir
1. ln âsf $TMPDIR ./tmp
2. echo â<HTML> Slawa </HTML>â > ./test.html
3. TMPDIR=./tmp lynx âdump ./test.html

    
Actual results:
hanging and $TMPDIR is filling with a TON of *.html

Expected results:
Few lines of test.html dump

Additional info:
Feel free to contact me for any details you need

Comment 1 Thomas E. Dickey 2003-05-18 00:29:00 UTC
On Redhat 8.0, I see lynx 2.8.5dev.7 (not a release).  I cannot reproduce this with the
current development version of lynx (2.8.5dev.15), nor with the current release (2.8.4).
Redhat's package is broken, of course.

Comment 2 Tim Waugh 2003-05-21 11:28:31 UTC
Can't reproduce this in Red Hat Linux 9.


Note You need to log in before you can comment on or make changes to this bug.