Re: lynx-dev symlinks to other users' files; broken symlinks

[pg]

In a recent note, Benjamin C. W. Sittler said:

> Date: Sat, 10 Oct 1998 16:09:04 -0600 (MDT)
> 
> Anyhow, is this sort of security really Lynx's business at all? It seems
> to me that managing symlink security is an issue for the user (who
> presumably created the link in the first place) to deal with. Let the
> users be responsible for their own mistakes, and teach them the dangers of
> symlinks to world-writable directories outside the context of Lynx. A
> little education can go a long way towards making Lynx's job easier.
> 
For a captive account, neither Lynx's configuration files nor its
temporary files should be in world-writable directories.  The temp
files and the directories containing them should be writable only
by the captive account; the config files and the containing directories
should be writable by an administrative account, and not by the
captive account.

for a full-featured shell account, the user should be allowed to
do whatever the system permits him.  It's not Lynx's business.
Lynx should respect the setting of the TMPDIR environment variable
at run time.  If the system doesn't support sticky bits, the user
can create a subdirectory in /tmp, writeable only by himself,
and point TMPDIR to that.

Of course, this presumes a system which supports multi-user security.

> Even in a well-administered system with many potentially-malicious users,
> allowing users to shoot themselves in the foot is probably more useful
> than preventing some creative collaboration of a form the administrator
> may not have considered.
> 
   "Unix was not designed to stop people from doing stupid things, because
   that would also stop them from doing clever things."
                                                               --Doug Gwyn

> Remember, the system is there for the users, not for the administrators.
> And if a user opens himself up to attack from other users, that's not the
> administrator's problem (unless that user happens to be the administator!)
> 
However, I once said something of this sort to an administrator, who
countered that when a user creates problems for himself, he generally
calls on the resources of the administrator to solve them.

-- gil