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: Larry W. Virden
Subject: Re: lynx-dev Re: what to do about html help files.
Date: Thu, 3 Jun 1999 05:49:07 -0400 (EDT)

From: Bela Lubkin <address@hidden>

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

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

What would we get rid of?  Compile time defaults are needed - I suppose
that more configure flags could be created to get rid of userdefs.h and
absolute defaults.  Environment variables need to be respected - though perhaps
the lynx specific variables could be moved into the lynxrc file.  A site
wide set of defaults should be supported, as should a user specific set
of defaults.  As long as there is some dissimilarities between options
that can be set - some of the lynx.cfg settings are items an admin will
allow a user to set and some are settings that s/he would not want them
to set, then two files are needed.  A run time setting for some features
seems necessary - whether both keyboard and menu are both needed is
debatable I suppose.

> options from one place or another.  Except that the names of the options
> vary.  We have the "-popup" command-line option, "USE_SELECT_POPUPS" in
> lynx.cfg, and "select_popups" in .lynxrc.

Here I agree though - let's bring all the options together so that the
same code is used - eventually moving to one form of the names would also make
documentation and use easier eventually.  Maybe a lynx 3.0 could be
envisioned which would do that?

> 
>   if (option.Security >= USER && option.User != UNSPECIFIED)
>     option.Active = option.User;
>   else if (Option.Security >= RC && option.Rc != UNSPECIFIED)
>     option.Active = option.Rc;
>   else if (Option.Security >= COMMANDLINE && option.CommandLine != 
> UNSPECIFIED)
>     option.Active = option.CommandLine;
>   else if (Option.Security >= CFG && option.Cfg != UNSPECIFIED)
>     option.Active = option.Cfg;
> 
> This means that we always know where the active value came from,
> according to the override chain.

We would want to discuss the priority rules - as they are likely to vary
depending on the option.

It seems that the normal non-security priority chain should be:
Highest: Run Time 
        Command Line
        Environment variable
        User's lynxrc file
        Site's lynx.cfg file
Lowest: compile time

That is to say, anything specified via the run time option menus would
override anything specified previously at any of the lower priority levels.

Now, for security priority chain, resolution would be somewhat similar with
one caveat - the setting remains the lesser of access options specified
at any point in the chain.

So, if the default for lynx is compiled as allowing local print options, but
that is turned off in lynx.cfg, the user should not be able to turn that
option back on by setting any lynxrc , environment variable, command line
switch or run time menu.

Question though - _should_ the user be able to turn that option back on
by providing their own lynx.cfg file, or should they have to build their
own lynx to be able to lessen security?
        
>   # only lynx.cfg can change the security of other options!
>   security:security:cfg
>   # only allow lynx.cfg to change whether cookies can be accepted
>   security:cookies:cfg
>   # users can choose whether searches are case-sensitive
>   security:case:user

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

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

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

That's going to be a bit confusing.  Also, I know _I_ prefer not to see
large files arbitrarily maintained in my directories by programs.
Perhaps what is written out is only those values that deviate from the
defaults.  With appropriate man page info, and lynx runtime support
for helping one set appropriate default values (and saving those values
into a runtime specified filename), that would be an option.
-- 
Larry W. Virden                 <URL: mailto:address@hidden>
<URL: http://www.purl.org/NET/lvirden/> <*> O- "No one is what he seems."
Unless explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.

reply via email to

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