[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<