Bug 89967 - lynx hangs on operation when lynx_temp_space contains directory which is link
lynx hangs on operation when lynx_temp_space contains directory which is link
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: lynx (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-30 10:06 EDT by Sysoltsev Slawa
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-21 07:28:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sysoltsev Slawa 2003-04-30 10:06:15 EDT
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-17 20:29:00 EDT
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 07:28:31 EDT
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.