Re: lynx-dev Re: who owns what

[Bela Lubkin]

Philip Webb wrote:

> > It also assumes that `ls -ld file` produces output, for symlinks,
> > which looks like:
> >   lrwxrwxrwx   1 filbo    armory        17 Oct  8 18:08 foo -> bar
> >                      `` -> '' sequence between link source ^^^^ target
> 
> i tried to create a link as described in K & P to test this,
> ie  ln ~/dir/test.d1 test.d2 , where  test.d1  exists in  ~/dir :
> it created  test.d2 , but subsequent test edit changes in each file
> had no effect on the other file &  ls -ld test.d1  showed nothing special.
> how do i create a link to test the command?

You created a hard link (but then it didn't behave as expected).  You
want a symlink: `ln -s source target`.

> > Show us the output of `pathto $HOME`.
> 
> i tried to execute it & got  syntax error in line 22: `;' expected .

I get that if I run it with the Bourne shell.  In order for the desired
shell to be invoked, the first two characters must be "#!", followed by
the shell name (there can't be any blank lines, leading spaces, etc.)
Some systems don't support that, but I would be surprised if that was
the problem here.  Anyway, you can explicitly invoke it as `ksh pathto
$HOME` (or bash).

> 981008 Bela Lubkin wrote: 
> > Philip Webb wrote:
> >> I (capitalised for once) have no security problem,
> >> nor do the majority of Lynx users & installers:
> >> these problems arise ONLY for sites with anonymous users.
> > No, you are 100% wrong here.  The security problem
> > this code is trying to avoid arises *ONLY* for NON-anonymous sites,
> > where you, a non-anonymous user, are innocently using Lynx.
> > Some other user, who has a full shell account, decides to attack you.
> > He places a malicious link into the directory Lynx is trying to use.
> > When Lynx creates a file in that directory, it is tricked into following
> > the malicious link, and overwrites one of your personal files.
> 
> how can the Enemy place a link in  ~/purslow ?  i own it.
> maybe in  /tmp , if the link is to a file under  ~/purslow ,
> but that's never going to be the case with  .lynxrc .

Enemy can't; the problem is that Lynx is using the same function to
check the safety of writing the .lynxrc as for writing a temp file.
Compounded by some weirdness of your system that makes the test fail
even though the directories and links appear to be properly protected.

However, when you disable ther checking code you are also disabling it
for times when Lynx *is* trying to write to /tmp; you're opening
yourself to the previously discussed problems.

> > This can only happen on systems where the attacker has access to a shell.
> 
> so why did the problem arise explicitly for anonymous Enemies,
> as is shown by the messages in the Archive i referred to yesterday?

You referred to 2 months worth of messages, I believe -- I didn't go
looking.  I'll follow a direct URL to a specific message.

> > And, in this case, Lynx is obviously being fooled by something unusual
> > about your system's directory structure.
>  
> i doubt if there's anything much amiss with CHASS:
> the sysadmin is overworked, but fully competent in my experience.

It's not "amiss", it's *unexpected*.  Though it's still unclear *what*
unexpected configuration oddity is bugging Lynx.

> nothing you've said above establishes there could be a problem
> on an ordinarily well-managed UNIX site without anonymous users,

There could be.  Even with a sticky /tmp directory, there are ways to
attack, and the code you patched out attempts to avoid those.

> which leaves me with the basic question unanswered:
> should lynx-dev be going to such lengths to protect vs anonymous enemies?

Please stop with the straw man.  I've told you repeatedly: the enemies
you're being slightly overprotected against are *anyone with shell
access* on the machine on which you run Lynx.  Yes, absolutely, 100%,
Lynx should be protecting against them.  Even if you somehow believe
there is nobody malicious, and never will be, on your system.

> i tried asking the slow way & got:
> 
>  ls -ld $HOME  gives:
>   
> lrwxr-xr-x    1 root     sys           18 Mar  5  1998
>  /homes/purslow -> /homefs/u7/purslow
> 
>  ls -ld /homefs/u7/purslow  gives:
>  
> drwx--x--x    9 purslow  user         512 Oct  9 07:53 /homefs/u7/purslow
> 
>  ls -ld /homefs/u7  gives:
> 
> drwxr-xr-x   32 root     sys          512 Oct  8 12:19 /homefs/u7
>  
>  ls -ld /homefs/  gives:
> 
> drwxr-xr-x   29 root     sys          512 Aug 25 23:41 /homefs

None of which appears to be the cause.  Now please run the pathto
script.

>Bela<