Re: pubLynx reinstated LYNX-DEV

[Jonathan Sergent]

Foteos Macrides <address@hidden> wrote:
 ] Jonathan Sergent <address@hidden> wrote:
 ] >Foteos Macrides <address@hidden> wrote:
 ] > ]  I don't plan to use an LYExec() for Unix downloader and printer
 ] > ] options, rather than just ensuring that the LYNXDOWNLOAD: and
 ] > ] LYNXPRINT: URLs are the paths or scripts derived from lynx.cfg, with
 ] > ] quote_path() applied to the arguments.  With the adequate protections
 ] > ] in place, I don't see any reason to block the Unix scripting capability,
 ] > ] which is a much nicer way, for example, to get around zmodem/sz's
 ] > ] inability to handle a second argument, than having to use an external
 ] > ] script file with execl().   The DIRED stuff is using execl(), because
 ] > ] that uses the paths defined in userdefs.h, and no scripts.

 ] >I don't see how not using system() and using scripting in downloader and
 ] >printer definitions are mutually exclusive.  All that system()
 ] >does is execl("sh","-c",arg,(char *)0).  Downloader definitions that
 ] >need shell processing (most of them, I guess) could have "sh -c"
 ] >prepended to them.

 ] >A more backward-compatible way to handle this would be to create
 ] >an EXECDOWNLOADER definition syntax of some sort that would run a 
 ] >     execl(download_command->command, cp, cp1);
 ] >... this would allow system admins to create "secure" downloaders.

 ] >This is all a bit paranoid I suppose, but an ounce of prevention...

 ]      I must be missing something, like having missed that I could
 ] make Lynx do things it shouldn't be able to do on Scott's solaris,
 ] because he had put me in the sysadmin group, although, aside from the
 ] headaches it caused Scott, that worked out for the best because I
 ] added protections against Lynx doing things it shouldn't do when
 ] you invoke it in the syadmin group. :) :)
 ] 
 ]      If you invoke execl() with a SHELL_PATH, can't the arguments
 ] be scripts, and if so, what have you gained?

Nothing, nothing at all.

If you invoke it without a shell, you gain something, though.

The idea is to allow the admin to specify that a shell should not be
used if the admin does not want a shell to be used, which is useful
if the admin is paranoid and doesn't want lynx to use system().

In these cases, the admin could specify only a pathname, which would
have the two filenames as arguments.

The admin wouldn't be forced to do this, but as things stand, if the
admin is concerned enough about security that he is willing to use
an external C wrapper to start the program safely, the arguments to
the program are still subject to shell globbing and such, and there's
no way around that.

So I guess what I think is that the current behavior should be kept
but the EXECDOWNLOAD should be available.

But that might just be me thinking paranoid thoughts.  The current
protection seems quite solid.

-----

quote_pathname suggestion: check filename for each character in
getenv("IFS") and strip them.

Off the top of my head:

if (cp = strchr(getenv("IFS") ? getenv("IFS") : " ", pathname[i])) 
   for(j=cp; *j; j++)
      *j = *(j+1);

Users may be able to set environment variables like IFS with
telnet.   The single quotes should stop this I suppose.


--jss.
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;