lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pubLynx reinstated LYNX-DEV


From: Foteos Macrides
Subject: Re: pubLynx reinstated LYNX-DEV
Date: Mon, 07 Jul 1997 14:34:03 -0500 (EST)

Foteos Macrides <address@hidden> wrote:
>Al Gilman <address@hidden> wrote:
>>to follow up on what Foteos Macrides said:
>>> 
>>>     As far as the LYNXDOWNLOAD: spoof is concerned, for public access
>>> sites which don't want the entire set of fotemods, they can just swap:
>>> 
>>>     http://www.slcc.edu/lynx/fote/patches/lynx2-7-1/src/LYDownload.c
>>> 
>>> into the vanilla v2.7.1 code set.  You can't also swap in LYMainLoop.c,
>>> so you won't get all the other niceties, but just the LYDownload.c swap
>>> will block the LYNXDOWNLOAD: spoof completely.
>>> 
>>
>>Is there anything more that Sailor needs to know about to recompile and
>>re-instate g)o-to service at their public site?  Or is that too broad
>>a question?
>>
>>My first reaction was "this description of the fix belongs in the FAQ"
>>and my second reaction was "or is there a more complete description
>>of the problem response somewhere else?"
>
>       I personally would have no squeemishness about using the current
>fotemods code set for anonymous accounts with 'g'oto enabled except for
>file URLs, and a /tmp/$USER TEMP_SPACE that has 700.  With just LYDownload.c
>swapped in to the vanilla v2.7.1, you still have the symbolic link problem,
>though you'd need shell access to attempt that spoof, which should be denied
>to anonymous users.

        I forgot to answer the second half of your question.  I added
a  "Security" related issues  link in http://www.slcc.edu/lynx/fote/
(which is the  "Lynx2-7-1"  link for http://lynx.browser.org/) for a
security.html that's based on the drafts Subir and Jonathan wrote, i.e.,
in the style of a CERT advisory, and covers both the LYNXDOWNLOAD: and
symbolic/hard link issues.

        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.

        On VMS, both the DECC and VAXC libraries have system(), execl(),
execle(), execlp(), execv(), execve(), and execvp(), but VMSers typically
roll their own using the lib$ and/or sys$ libraries, as I've done in
Lynx.  The latter allows you to tie in explicitly to the CAPTIVE setting
for accounts, which is a straighforward why on VMS to do what chroot jails
appear to be seeking.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]