lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev -anonymous broken in 2.8.4?


From: RobertM
Subject: Re: lynx-dev -anonymous broken in 2.8.4?
Date: Sat, 7 Sep 2002 00:55:58 +0100 (BST)

It is alleged that Bela Lubkin once typed:
> > > > ANONYMOUS_RESTRICTIONS="file_url,download,lynxcfg_info"
> > > better LYNX_RESTRICTIONS
> > Yes. That would make more sense and probably more widely useful.
> Wait a sec... is the idea to restrict all users of Lynx or only when
> Lynx is run with "-anonymous"?
> Perhaps two different options are wanted here.

Possibly, though looking at most of the restrictions for lynx many of
them don't make sense if the person has any sort of real shell
account.

> Do people who run anonymous Lynx services build customized Lynx binaries
> for them, or do they share a single binary between the service and their
> own private (unrestricted) use?

I can't speak for anyone else, but for the anonymous lynx server I
look after I use a custom build. then again I also build it statically
and run it chrooted.

[snip]
> In both cases, it would be good to have them as runtime-configurable
> options (e.g. in lynx.cfg), not purely compile-time.  I _do_ understand
> that some admins may choose to build a separate Lynx binary to be used
> _only_ for their anon Lynx service, in which case they would be wise to
> compile dangerous options right out of the program.  But neither of the
> proposed settings sounds like it would do _that_.

If the options are in lynx.cfg they could in theory be toggled by the
user, all of the restriction options can be enabled at runtime. I
already compile out as many of the dangerous options as I can, but
currently there is no way to compile out access to file:/// urls,
wihtout seriously mucking about with the code. Being able to hard code
in a list of restrictions would be a "simple" way to enable such a
thing without having to have an even longer list of:
CAN_ANONYMOUS_<whatever> FALSE
than already exists. Also if new restrictions are added they'd
automatically be available without having to add extra code.


> Ideally we would have:
>   - ability to compile "-restrictions"-controllable functions right out
>     of the program (configure/compile options), to reduce the chance
>     that a tricky user might figure out how to get around runtime
>     restrictions.  This currently exists in ad-hoc fashion for many, but
>     I think not all, of the restrictable functions.

Correct.

>   - ability to restrict some options from all users ("LYNX_RESTRICTIONS"
>     setting in lynx.cfg -- note, requires compile-time ability to
>     specify a lynx.cfg file which _must always_ be applied, and which,
>     if it specifies restrictions, causes any further lynx.cfg files or
>     command-line restrictions to be ignored or processed only as
>     _additional_ restrictions)

That would be a must for it to be useful at all, though still not as
secure as having the options compiled into the lynx binary.
 
>   - ability to define a shorthand ("ANONYMOUS_RESTRICTIONS" setting in
>     lynx.cfg), so that running `lynx -anonymous` restricts an
>     admin-specified set of capabilities.  This is really just a
>     convenience, it only applies if the user is in a controlled
>     environment where the admin is supplying the Lynx command-line
>     options (i.e. "-anonymous").  Convenient because there may be
>     several such Lynx invocations throughout the admin's controlled
>     environment; this provides a single point of control.

This is less useful as if the user is being forced to run lynx with
-anonymous you could just as well also force them to run it with
-restrictions=whatever
Also at least for myself the anonymous lynx client doesn't use the
anonymous switch but is instead run by the anonymous user.

-- 
Robm
873
  "Ask not what I can do for the stupid, 
         but what the stupid can do for me" - Graeme Garden

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

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