From owner-freebsd-hackers  Fri Oct 18 17:07:02 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id RAA03076
          for hackers-outgoing; Fri, 18 Oct 1996 17:07:02 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA03021
          for <freebsd-hackers@FreeBSD.org>; Fri, 18 Oct 1996 17:06:13 -0700 (PDT)
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.6/8.7.3) with SMTP id QAA14002; Fri, 18 Oct 1996 16:52:41 -0700 (PDT)
Message-ID: <326817C5.61133CF4@whistle.com>
Date: Fri, 18 Oct 1996 16:50:29 -0700
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Andrew.Tridgell@anu.edu.au
CC: Guido.vanRooij@nl.cis.philips.com, freebsd-hackers@FreeBSD.org
Subject: Re: fix for symlinks in /tmp (fwd) FYI
References: <96Oct19.085926+1000est.65030-172+211@arvidsjaur.anu.edu.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

Andrew Tridgell wrote:
> 
> > I wonder if anyone can comment on this...
> > My initial reaction is that it's breaking the expected behaviour
> > or the system to do this....
> 
> yep, but we need to think of cases where "normal" use of symlinks will
> break. Can you think of any?

"hey john, I set a symlink in /tmp pointing to all that stuff you need"

or

"hey, you asked me to check the compile of that stuff you left in /tmp
for me but it doesn't work for me!" (he set one .h files as a symlink
to a bunch of stuff elsewhere)

"hey you said that if I used your 'lndir'd sources you left in /tmp
for me, I'd see the error messages but it totally barfs for me! "


It's probably not THAT common, but it MIGHT cause someone to lose hours
in a very frustrating way..

> 
> > If I see a symlink I expect it to be followed..
> 
> yes, and if you created the symlink, or if the symlink is not in a
> directory with the t bit set (such as /tmp) then it will be.
> 
> It just stops other people saying "if I create a symlink in /tmp then
> I expect that other guy to follow it (he he he)".

I still don't see the danger in that though....
Is this something that surprising?

tmpfile creation should not follow a symlink anyhow..

> 
> I think that the change actually fits in well with the existing t bit
> behaviour. The t bit already modifies how permissions work in /tmp,
> I'm just extending this slightly because following a link in a world
> writeable directory is just as dangerous as deleting a file.
> 
> > I just don't like it?
> 
> Have another coffee then think of a better reason :-)
> 
> It may be that my fix breaks something important. I just haven't
> thought of what that is yet ....
> 
> Cheers, Andrew