Re: lynx-dev sidenote on early removal of files passed to viewers

[Klaus Weide]

> > (I'm wondering
> > why you are still doing removal in lynx, rather than in your viewer
> > scripts - but we discussed that, long time ago.)
On Mon, 20 Dec 1999, Henry Nelson wrote:
> Don't trust myself to write a secure script; also, I really don't want
> public access people to even have the ability to execute a shell, let
> alone run a script.  Same [sick] psychology as "if (iscntrl(FROMASCII
> (from_hex(p[1])*16 + from_hex(p[2]))))" in HTParse.c: stop the monkey
> business before it starts.

Well, you're not sick, just cautious... :)

But I'd like to know whether there *is* any additional danger involved
in using a shell script wrapper.  I don't think so, but maybe someone
who knows better can tell us more.

Considering the following two cases:

(a)
     VIEWER:application/x-some-type:/usr/local/bin/most +s %s

(b)
     VIEWER:application/x-some-type:/usr/local/bin/most-and-rm.sh %s

     with a /usr/local/bin/most-and-rm.sh containing:

     #! /bin/sh
     /usr/local/bin/most +s "$1"
     /bin/rm "$1"


(Replace "/usr/local/bin/" with whatever is appropriate in the situation -
it may be some special "safe" place only used by and for the lynx
account.  Maybe /bin/rm should also go there.
Replace "most +s" with whatever command *is* regarded safe enough to
use in the situation.  This command is just an example - although,
supposedly and according to lynx.cfg, "most +s" is safe, whatever
that means exactly.
Replace "application/x-some-type" with some real type, of course.)

Does case (b) increase the opportunity for "monkey business" in any way?

Things to consider:
- Lynx calls VIEWER commands using system(), and system already uses
  /bin/sh.  On anything resembling Unix, AFAIK.  So whatever problems
  there are with executing a shell process for interpreting
  /usr/local/bin/most-and-rm.sh already would exist in case (a).
- We can know that the single argument (%s in the VIEWER option, $1
  in the script) is always a temp file generated by Lynx, in the usual
  temp space.  So no funny business with spaces or special characters
  in the filename (if the temp directory name is safe - if not, there
  is no safety anyway).
- Assume it doesn't matter to Lynx whether the file exists after the
  VIEWER command returns.


  Klaus