Just my two cents...

I prefer conceptually ownerless symlinks.  It adds simplicity to the
filesystem interface.  I don't think that cluttering up the kernel, NFS
code, tar/cpio, etc. with an understanding of symlink ownership is a
good idea.  SYMLINK, READLINK, and LSTAT is all that that is necessary.
I don't want LCHOWN, LCHMOD, LUTIMES, or anything else.  If symlink
ownership is significant in any way, then you definitely need LCHOWN
(e.g. root should be able to restore/move a tree using tar or cpio and
not mess up any access that users have).

Another benefit that this buys you is implementation flexibility.
Symlinks can be done however is convenient for your filesystem (as a
special kind of "inode"; with their contents stored directly in the
directory; using the UID/GID inode fields to store the contents of the
link in the inode itself; whatever).

As for the problems with sticky-bit directories, I think that the real
source of the trouble is that sticky-bit directories are themselves a
hack which is not properly thought out and implemented.

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.

My vote is to fix the sticky-bit hack, so that:

    -- A user can't make a hard link from a file he doesn't own into a
    directory where sticky-bit access applies.

    -- A user can't make a symbolic link in a directory where sticky-bit
    access applies.

    -- A user can't make a whiteout in a directory where sticky-bit
    access applies (although this is really a non-issue, when you think
    about it).

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.

--Lon Willett
  willett@math.utah.edu