From owner-freebsd-security  Tue Feb 27 23:32:52 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id XAA18959
          for security-outgoing; Tue, 27 Feb 1996 23:32:52 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA18949
          for <security@freebsd.org>; Tue, 27 Feb 1996 23:32:48 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA31286; Wed, 28 Feb 1996 18:30:59 +1100
Date: Wed, 28 Feb 1996 18:30:59 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199602280730.SAA31286@godzilla.zeta.org.au>
To: bde@zeta.org.au, roberto@keltia.freenix.fr
Subject: Re: Suspicious symlinks in /tmp
Cc: msmith@comtch.iea.com, nlawson@kdat.csc.calpoly.edu, security@freebsd.org
Sender: owner-security@freebsd.org
Precedence: bulk

>> I think this is to conform to future POSIX standards.  Many other things
>> involving symlinks changed in 4.4lite.  See `man 7 symlink'.

>davidg also said it was not to use an inode for the symlink itself so every
>symlink in 4.4BSD are  fast symlinks (as it  was possible to use in FreeBSD
>1.1.5.1). 

Fast/small symlinks use an inode but not a data block.  Very fast/small
symlinks would use only a directory entry (or two).  Then there would be
nowhere to store the uid etc.

>It don't like our behaviour  either. Highly counterintuitive and deadly for
>sticky directories too where a user can't remove a link he made.

Very intuitive if you don't know about inodes :-).

Bruce