lynx-dev if lynx.cfg is unavailable (was: disabling charsets)

[Klaus Weide]

On Wed, 31 Mar 1999, Bela Lubkin wrote:
> Klaus Weide wrote:
> 
> > Is it a good thing that a Lynx dissociated from its support files is still
> > usable?
> > 
> > Lynx intentionally refuses to work when it finds no configuration file.
> > None of the lynx.cfg is really required for running: lynx -cfg=/dev/null
> > runs.
> 
> This was last discussed when Fote was still running the show.  It seemed
> to be a religious matter with him, so I didn't push my point of view.  I
> think that yes, it *is* a good thing that a bare Lynx binary can run.
> As you say, nothing is actually needed from lynx.cfg.  I often need an
> ad hoc Lynx binary on a bare machine where I'm not root.  I can copy the
> binary over; I can't copy the support files into the compiled-in
> locations they're expected to be in.  I can dork around with environment
> variables or flags.  I don't *want* to.  The only thing that prevents a
> bare Lynx binary from running is its insistence on reading a file that
> it doesn't need.  Silly.

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 has advantages.  It's nearly impossible to _accidentally_ install
> > lynx without a lynx.cfg.  And if the lynx.cfg somehow gets lost, the
> > problem becomes apparent immediately.
> 
> Yeah, it becomes apparent immediately, and ticks me off.  Every time.

And it tells you what's wrong.  Every time.  And you know how to make it
run, specify /dev/null, and it should work with every ad hoc Lynx binary
you find on a machine or copy to it, every time.

If it's the same Lynx binary that you carry around with you while visiting
those machines, compile it with #define LYNX_CFG_FILE "/dev/null" in
userdefs.h.

If you are talking about lynx binaries that already exist on the machines,
changing anything in the devel code now wouldn't save you from encountering
this anyway.  And if it's only an optional change, you could never rely
on it.

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