lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Re: what to do about html help files.


From: Bela Lubkin
Subject: Re: lynx-dev Re: what to do about html help files.
Date: Thu, 3 Jun 1999 03:53:45 -0700

Larry W. Virden wrote:

Bela>> We have far too many runtime configuration mechanisms.  There are
Bela>> internal defaults (some compiled in from userdefs.h or config.h, others
Bela>> are absolute Lynx defaults); a few environment variables; command-line
Bela>> options; lynx.cfg and its included files; .lynxrc; two different options
Bela>> menus; and a number of keyboard toggles (like '^V' -> SWITCH_DTD).

Larry> The only thing in this list that I would consider 'too many' is 
Larry> "two different options menus".  I guess I would consider lynx to have
Larry> an appropriate number of mechanisms that perhaps need some tuning.

We do not disagree.  I didn't mean that we should get rid of these
external manifestations, but rather that we have too many
*implementations* of configuration mechanisms.  I propose to keep all
the same externals, but replace the internals with a single unified
system.

Larry> Question though - _should_ the user be able to turn that option back on
Larry> by providing their own lynx.cfg file, or should they have to build their
Larry> own lynx to be able to lessen security?

This question is answered by the administrator.  If he provides no
command-line access to Lynx, the answer is "no".  Or, according to my
prototype scheme, if he *compiles* Lynx with:

  LynxOptions[LynxCfgFile].Security = CFG

then the binary will not accept the -cfg command-line option.  I would
expect the default to be USER; that is, if you can get to a command
line, you can specify the cfg file.

Bela>>   # only lynx.cfg can change the security of other options!
Bela>>   security:security:cfg
Bela>>   # only allow lynx.cfg to change whether cookies can be accepted
Bela>>   security:cookies:cfg
Bela>>   # users can choose whether searches are case-sensitive
Bela>>   security:case:user

Larry> Interesting idea - what do others think ?  My first thought was that
Larry> this might make it easier for someone to compromise a limited system.
Larry> However, _IF_ the admin is paying attention to security (and if they
Larry> begin the effort of trying to lock users into 'secure' uses of lynx
Larry> they had better plan on going the whole way...) then it seems to me that
Larry> the same efforts to keep the original lynx.cfg and lynx binary should
Larry> suffice to protect the new lynx.cfg file.

Any security system is a metastable peak, not a valley -- it's easy to
fall down the hill.

If this idea was implemented, I don't think it would be difficult to
provide in the Lynx distribution a pre-configured secure-for-anon
lynx.cfg.  With comments, of course...

Larry> I suspect that a well written article on how to set up lynx securely is
Larry> really needed.  I know this has come up before in the group.

Indeed.  The form of such an article might as well be copious comments
embedded in a live, workable "secure" lynx.cfg.

Bela>> out as a copy of a lynx.cfg (in which case many of its options will
Bela>> probably be ignored because the user isn't allowed to change those
Bela>> things).

Larry> That's going to be a bit confusing.  Also, I know _I_ prefer not to see
Larry> large files arbitrarily maintained in my directories by programs.

Whoa... I certainly didn't mean to imply that Lynx would copy lynx.cfg
*for* the user.  I meant, as an example of the flexibility of this
scheme, that a user *could* copy lynx.cfg to his .lynxrc, and the
resulting configuration would behave sanely.

Larry> Perhaps what is written out is only those values that deviate from the
Larry> defaults.  With appropriate man page info, and lynx runtime support
Larry> for helping one set appropriate default values (and saving those values
Larry> into a runtime specified filename), that would be an option.

The "file to save into" is ~/.lynxrc (or equivalent on other OSes).

Deciding what to write out is one of the tricky bits.  Suppose I
experiment with a setting, first changing it the opposite of what was
set by lynx.cfg; then later changing my mind and setting it back.  The
setting now does not "deviate from the defaults".  Now, suppose that my
sysadmin *also* decides to change the value of that setting.  If Lynx
has not recorded my final decision -- that I like it the way lynx.cfg
originally had it -- then my setting mysteriously changes.

How to handle this?  In the New Improved Futuristic options widget, it
can show lots of detail:

  "case"   Searching type (CASE SENSITIVE or IGNORE CASE):

     Current setting is CASE SENSITIVE, from /local/lib/lynx/lynx.cfg

[after toggling once:]

     Current setting is IGNORE CASE,    from user options menu
              Overrides CASE SENSITIVE, from /local/lib/lynx/lynx.cfg

[after toggling again:]

     Current setting is CASE SENSITIVE, from user options menu
                Affirms CASE SENSITIVE, from /local/lib/lynx/lynx.cfg

[after saving options:]

     Current setting is CASE SENSITIVE, from ~/.lynxrc
                Affirms CASE SENSITIVE, from /local/lib/lynx/lynx.cfg

[after toggling again, but not yet saving:]

     Current setting is IGNORE CASE,    from user options menu
              Overrides CASE SENSITIVE, from ~/.lynxrc
              Overrides CASE SENSITIVE, from /local/lib/lynx/lynx.cfg

>Bela<

reply via email to

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