Re: lynx-dev Lynx 2.8.3 with nmh problems

[Klaus Weide]

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

> Okay, here's a partial explanation.  When invoked through nmh, the
> temporary directory's permissions appear to be not 700 but 600, even
> though the strace clearly calls mkdir with mode 700.  Obviously this
> prevents creation of the temporary file.
> 
> drw-------    2 mas      mas          1024 May  7 16:46 pN5pOH
> 
> I don't see anything in the strace that could be causing this, though.
> When run directly, the mode is 700 as it should be.

It must be an umask() call in mhnshow or metamail then, which gets
inherited by the lynx process.  (You can reproduce this with an
explicit 'umask' command from the shell - see my other mail.)

> Klaus> Also, under strace you would get longer traces to compare - a
> Klaus> difference has to show up somewhere...
> 
> I did my best to eliminate differences between the two.  Started in
> the same directory, viewing the same file name with same contents,
> same null config file.  In both cases I started lynx (once through
> mhshow, once directly), hit Backspace for history, then `q' and `y' to
> end the session.  The only differences between the straces I can find
> (with ediff) are:

Thank you for checking all this.

> * Filehandle numbers
> * PIDs
> * Times of day and execution times
> * Name of Lynx's temporary directory and temporary file
> * Pointer addresses
> * When invoked directly, the "Are you sure you want to quit?" message
>   has more console escapes in it:
>     write(1, "\r\33[0;10m\33[1m\33[33m\33[44mAre you su"..., 57) = 57
>   versus
>     write(1, "\rAre you sure you want to quit? "..., 56) = 56
>   and then later we have
>     write(1, "\r\33[0;10m\33[30m\33[47m\33[K", 21) = 21
>   versus
>     write(1, "\r\33[K", 4)                  = 4

Hmm, there must be a difference in the TERM environment variables
then.  But this shouldn't have anything to do with the temp file
problem.

> * When invoked directly, the history command works, and when invoked
>   through mhshow, it doesn't!
> 
> I must admit to absolute cluelessness about what could be changing the
> directory mode.  Any suggestions on how I could find out when it
> happens or who does it?

I thought (without checking) that a process's umask would be visible
somewhere under /proc/<pid>, but apparently that's not the case (or not
in an easily recognizable form).

> Klaus> What happens if you create a temp directory somewhere (in the
> Klaus> user's home space), with regular permissions for the user, and
                                  ^^^^^^^^^^^^^^^^^^^
> Klaus> direct TMPDIR/ LYNX_TEMP_SPACE to that?
> 
> The same thing as when it's /tmp.  The new directory has mode 700 when
> run directly, mode 600 when run by mhshow.

For Debian, "regular permissions" should mean that the directory has
group write permissions (drwxrwxr-x).  If you remove that (chmod g-w
~/your-tmp), the code in lynx that creates a subdir should not be
activated.  Everything should work fine, you can use this as a temporary
workaround.

Another workaround would be to replace the lynx invocation (in /etc/mailcap)
with a simple lynx.sh script, something like

  #! /bin/sh
  umask 002   # or 022, or even more restrictive like 077
  exec /usr/bin/lynx "$@"

 Klaus


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