Re: lynx-dev PATCH for ENABLE_RC

[RobertM]

It is alleged that Doug Kaufman once typed:
> On Sun, 15 Jun 2003, Thomas Dickey wrote:
> > actually there are still some users who access lynx via a public service
> > (probably not many).  So I was keeping that situation in mind.

Well for lynx.scramworks.net I'm seeing about 13 users a day everyday, and
that's been fairly consistant for a while.
/* the public stats page is currently broken */

> Yes, these are the users I was asking about. Is anyone who is accessing a
> public access version of lynx going to have editing privileges for a
> lynxrc file (as opposed to being able to save the file from lynx), but
> not have editing privileges on a lynx.cfg file in their home directory?

Well for the version on lynx.scramworks.net the guest users don't have
access to edit anything, they can change some of the options but certainly
not save them. I do have a non-editable .lynxrc in the guest users
directory just so to make sure I don't break anything,when testing a new
version.

> Can't the same degree of security be obtained with the "INCLUDE for"
> restrictions in lynx.cfg if the administrator puts a
> "INCLUDE:~/lynx.cfg for ..." at the end of the systemwide lynx.cfg file?
> 
> If there is no security problem, I still think it is cleaner to have all
> the options that must be hand-edited in lynx.cfg and only keep those
> that are adjusted by the OPTIONS page in the lynxrc file.

Unless the guest user can access thier home diretcory to edit the lynxrc I
can't see a problem with that, would make things easier from an admin point
of view. At least as far as I'm concerned. I would have though that
splitting things out like that would actually improve security as it takes
the most important settings out of the users home directory.

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