Re: lynx-dev if lynx.cfg is unavailable

[Klaus Weide]

On Thu, 1 Apr 1999, Jean-Pierre Radley wrote:

> Klaus Weide averred (on Wed, Mar 31, 1999 at 07:14:12PM -0600):
> | 
> | It doesn't need it in order to run somehow.  It needs it in order to
> | know how it is meant to run.  It doesn't know whether 'lynx.cfg not
> | available' is an acceptable condition or not, so it acts according
> | to 'better safe than sorry'.
> 
> This is nonsense.  The manual should say, and lynx should act as if the
> manual said:
>       Lynx is compiled to use settings, options, and URLs defined
>       in certain source code files.  Many of those settings can be
>       overridden in an optional lynx.cfg file, which must be in a
>       directory defined in those source code files (usually it would
>       be /usr/local/etc/lynx.cfg).

How does that make what I wrote "nonsense"?  The manual does not say 
what you think it should say, and lynx doesn't act as you think it should.
Obviously your ideas of what lynx should do differ from what it does, and,
assuming this isn't all just accidental, from what previous developers of
the code have thought.  I was trying to give a reason why things are as
they are.  You are stating how things should be (without giving any
reasons).  Different thing.

> [If the man pages were written like those of smail, then that last
> parenthetical remark wouldn't be necessary, since the man page would
> carry the precise location where a lynx.cfg file would exist.]
> 
> IOW, there is nothing "unsafe" to be "sorry" about if lynx uses the
> settings used at compile-time; there is nothing "unsafe" to be "sorry"
> about if there's no lynx.cfg file to override any of those defaults.

There may well be nothing unsafe to be sorry about in your situation,
the way you have configured Lynx before compilation and have set it
up in your lynx.cfg.  That doesn't mean it has to apply to everyone.

You have ignored (and snipped) the part of my message that dealt with
an unsafe situation.  Since for this reason the message isn't archived
at www.flora.org, I repeat the relevant part at the end.

More generally, yes there's nothing to be sorry about if lynx uses
the compiled-in settings AND it is intended to use them.  There would
be something to be sorry about if lynx used the compiled-in settings
when it's not supposed to (they are supposed to be overridden by
lynx.cfg), by accident.  So far this isn't different from any program
that uses any kind of configuration file.  I would not argue that
any such program should refuse to run if the config file is missing.
But lynx's configuration file can be used to impose restrictions
beyond the compiled-in settings.  Running lynx at all without these
restrictions may be unacceptable.

By the way, these restrictions don't just apply to multiuser sites or
sites with guest accounts.  Some of them are needed to protect a single
user.  Take TRUSTED_LYNXCGI.  I may have compiled with LYNXCGI_LINKS
since I want lynxcgi sometimes.  But I want TRUSTED_LYNXCGI:none
(or something a bit less restrictive) during normal browsing, or someone
might sneak in a link that would 'accidentally' erase all my files when
I follow it.

   Klaus


---------- excerpt from previous message ---------
> > That's in addition to considerations for anonymous or otherwise restricted
> > accounts.
> 
> I don't see any interaction with these.  If your anonymous/restricted
> user can get out to a prompt and run arbitrary binaries (such as a Lynx
> which has been compiled for a lynx.cfg path other than the one your
> system uses), he's already busted out of his sandbox.

If the anonymous/restricted user can not get out to a prompt, but lynx at
startup cannot find the lynx.cfg at the configured location and then
proceeds as if it had found an empty lynx.cfg file, the anonymous/restricted
will get all those permissions that lynx.cfg, if found, would have turned
off (unless they are irrevocably turned off already at compile time).
Not finding a vital lynx.cfg could be caused by various things, among them
admin error, unmounted filesystem, possibly even temporarily unavailable
filesystem.