> Consider the following aspects of *hard* links and sticky-bit
> directories:
> 
>     -- Hard links retain no trace of their creator.
> 
>     -- A user can make a hard link from a file he doesn't own into a
>     sticky-bit directory, and then not be able to remove this link.
> 
>     -- A user can fill up a sticky-bit directory with hard links, making
>     the directory ever larger, and thus using up the disk quota of the
>     owner of the directory.
> 
>     -- In general, because a user can make hard links to files he
>     doesn't own, the quota system is rather compromised anyway.
>     Especially since many programs (e.g. cc) use /tmp, /var/tmp, or
>     other publicly readable and executable directories.

	You miss one key point.  A hard link _must_ be on the same
file system as the thing it's linking to.  In a directory like 
/tmp things to link to probably aren't going to be around for
long, and moreover are generally deleted every so often automatically
anyway.  Think of how hard it would be to compile
emacs in /tmp if it couldn't make it's hard link.

	The argument that they are untracable and use up a lot of
space just doesn't float with me, people downloading 3 copies of the
Linux distribution into your /tmp wastes space.

> My vote is to fix the sticky-bit hack, so that:
> 
>     -- A user can't make a symbolic link in a directory where sticky-bit
>     access applies.

	I really don't like this.  There have been many times I 
needed to make symbolic links in /tmp to compile a package there.
It's an easy way to "move" a whole tree while using almost no
disk space.  If anything the argument should be for getting rid of
hard links, not soft links.

> Given the above, I don't really care what goes in the owner/group fields
> of a symlink (that is the point).  On the one hand, it would
> occasionally be nice to see who created them, but this isn't critical
> (and see the first note about hard links; it would occasionally be nice
> to see who made them too, but I don't think that this should be
> implemented in the filesystem).  On the other hand, using the directory
> owner/group for symlinks is a good LCD way to fill in a "meaningless"
> field, and could continue to work consistently regardless of the
> implementation.

	If you're going to allow people to make symbolic links in
directories like /tmp (with world write permission) then they need
an owner so you know you can delete them.


	I think to prevent the most problems:
1) You should not be able to hardlink to a file you don't own
   (unless root, of course).
2) Symlinks should have owners, and be able to point to files
   you don't own.

	Also, something else I think should be done to remove
more confusion is that chmod, chown, chgrp on a symlink should
change the symlink, not what it points to.  There need not be
special commands to change the symlink.  If I wanted to change
what it pointed to, I would go there and change it.

-- 
Leo Bicknell - bicknell@ufp.org    | Make a little birdhouse
               bicknell@vt.edu     | in your soul......
               bicknell@cs.vt.edu  | They Might
http://www.ufp.org/~bicknell/      | Be Giants