Re: lynx-dev Lynx 2.8.3 with nmh problems

[Klaus Weide]

On Sun, 7 May 2000, Michael Abraham Shulman wrote:

> I set LYNX_TEMP_SPACE to /tmp and recreated the error.  This time in
> Lynx.trace I get:
> 
> LYOpenTemp(,.html,w)
> -> '/tmp/blIU0d/L12663-4762TMP.html'
> ... LYOpenTemp(/tmp/blIU0d/L12663-4762TMP.html) failed: Permission denied
> Lynx: Can't open temporary file!
> LYCleanupTemp removing /tmp/blIU0d
> 
> So it looks like the double-// isn't the primary problem, at least.

Ok - probably just cosmetic.

> Klaus> You may want to start lynx with a minimal config file.
> 
> When I do this, the problem disappears.  I experimented a bit, and
> apparently setting GLOBAL_MAILCAP to /dev/null is what does it.  (I
> commented out everything else in the null config file and it still
> works.)

I expect that, with GLOBAL_MAILCAP set to /dev/null, lynx will start
up fine, but then anything you do whithin lynx that requires a temp
file will fail.  That includes viewing the History List (backspace key)
and a number of other User Interface pages like '=', 'L', ..., as well
as 'd'ownloading of a file.  Could you verify this?

> Klaus> Could you check whether the temp subdirectory is created at
> Klaus> all?  And if yes, with which permissions?  (running under
> Klaus> strace probably will show that, see below)
> 
> Klaus> You may want to run lynx under strace, and again try to figure
> Klaus> out where the relevant differences are;
> 
> Did this (returning to normal config file).  The relevant lines appear
> to be:
> 
> ...
> stat("/tmp/IihoXi", 0xbffff71c)         = -1 ENOENT (No such file or 
> directory)
> mkdir("/tmp/IihoXi", 0700)              = 0
> ...
> open("/tmp/IihoXi/L12910-2160TMP.html", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 
> EACCES (Permission denied)
> rt_sigaction(SIGHUP, {SIG_DFL}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGTERM, {SIG_DFL}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGINT, {SIG_DFL}, {SIG_DFL}, 8) = 0
> rmdir("/tmp/IihoXi")                    = 0

So "/tmp/IihoXi" had been created; moreover, it was still there at the time of
the open attempt (otherwise the rmdir() should have failed).
> ... [dies]
> 
> When I strace lynx opening a normal html file, the corresponding lines
> look like:
> 
> ...
> stat("/tmp/vIGn1b", 0xbffff7ac)         = -1 ENOENT (No such file or 
> directory)
> mkdir("/tmp/vIGn1b", 0700)              = 0
> ...
> open("/tmp/vIGn1b/L13090-1787TMP.html", O_WRONLY|O_CREAT|O_EXCL, 0600) = 5
> ... [succeeds]
> 
> It looks like lynx is doing the same thing in both cases, but failing
> for some reason when run by nmh.  The only thing I can think of is
> that nmh is running lynx as a different user who ends up not having
> write access to the temporary directory, since its mode is 700.  But I
> don't see why that would matter, since lynx creates the temporary
> directory, so whoever it's running as should be the owner, right?  I
> don't see anything in the strace that indicates the user is changing.

You should find some getuid() call in the strace output.  But that shows
only one of the various ID sets ("real", "effective", ...).

Is any of the involved programs setuid or setgid?  (mhnshow, metamail,
lynx)  They shouldn't of course.

Some more things to check -

What are the permissions/ownership on /tmp itself?

What happens if you create a temp directory somewhere (in the user's
home space), with regular permissions for the user, and direct TMPDIR/
LYNX_TEMP_SPACE to that?

Are you trying all this as a normal user, or as root?

> How could I find out who owns the temporary directory and who lynx is
> running as?

If the "GLOBAL_MAILCAP:/dev/null" acts as I expect (temp file
creations still fail), you can bring up lynx in both ways (direct and
via mhnshow), and then examine the directories at your leisure from
another window or console.  As well as the processes (try ps, and
especially "cat /proc/<pid>/status" - that should show all the uid/gid
sets - and other stuff under /proc/<pid>).  Also, under strace you
would get longer traces to compare - a difference has to show up
somewhere...

> I can attach the strace files if you want.

If all else fails... but it's easier if you can find the difference
yourself.

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden