From owner-freebsd-hackers Fri Oct 18 16:03:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA29388 for hackers-outgoing; Fri, 18 Oct 1996 16:03:41 -0700 (PDT) Received: from arvidsjaur (arvidsjaur.anu.edu.au [150.203.160.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA29380 for ; Fri, 18 Oct 1996 16:03:38 -0700 (PDT) Received: by arvidsjaur.anu.edu.au id <65030-172>; Sat, 19 Oct 1996 08:59:26 +1000 From: Andrew Tridgell To: julian@whistle.com CC: Guido.vanRooij@nl.cis.philips.com, freebsd-hackers@FreeBSD.org In-reply-to: <3267F479.773C2448@whistle.com> (message from Julian Elischer on Fri, 18 Oct 1996 14:19:53 -0700) Subject: Re: fix for symlinks in /tmp (fwd) FYI Reply-to: Andrew.Tridgell@anu.edu.au Message-Id: <96Oct19.085926+1000est.65030-172+211@arvidsjaur.anu.edu.au> Date: Sat, 19 Oct 1996 08:59:12 +1000 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 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? > 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 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