>> 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.

    > I disagree. In the 'bored undergraduate' environment that sticky
    > dirs were created for (to quote someone else on this thread ;), I
    > often used to extract packages or tar files in /tmp (setup as
    > sticky) because of quota or disk space limitations in ~. Having
    > the OS tell me 'ECANNOTMAKESYMLINKBECAUSEOFPOSIX' at that stage
    > would have made me extremely pissed.

Excuse me if I'm missing something, but I've worked in "bored
undergraduate" environments too.  And I've had to use /tmp for the same
reasons.  But typically, I'll do something like:

        cd /tmp; tar xzf emacs-19.29.tar.gz

which would work, because everything goes into the directory "emacs-19.29",
which is *not* a sticky bit directory, and which *I* own anyway.  Or,
I'll do something like:

        cd /tmp; mkdir lon; cd lon; tar xf ...

I don't like to put a big mess into the top level of /tmp anyway, so
other than a few miscellaneous files, I work in subdirectories that *I*
own.  Making this a requirement when you need symlinks in the top-level
of your project root doesn't seem like a big deal to me...

    > Sure, I can hard link to a file I don't own, but if *I* hard link
    > to a file I *do* own I'd want to be able to remove it.

Re-read what I wrote: you would be able to.  What I think you shouldn't
be able to do is hard link to a file you *don't* own, because then you
can't remove it (go try it).

    > Maybe change the semantics so that a user can't hard link or sym
    > link to a file they don't own in a sticky dir if you really must
    > keep this 'ownerless' concept.

For hard links, that's what I suggested.  For symlinks, you don't want
its target to matter (discussed elsewhere on this thread), so they would
be forbidden altogether.  If you must have one, make yourself a subdir
and put it in that.

    > However, I think that ditching the new semantics is a good idea,
    > UNLESS someone actually comes up with a reasonable reason why
    > they're needed (e.g, some braindead OS with potential POSIX
    > aspirations can't handle the traditional format of symlinks...)

The real reason to use the POSIX semantics is to avoid having to make
tar/cpio/every-other-archiver understand symlink ownership; and to avoid
having to implement "lchown" and l-every-other-inode-manipulating-syscall,
and then having to make NFS deal with them.  And then you'll still have
problems with older NFS servers that don't give you "lchown" or don't
support it in their underlying FS.

Again, perhaps I've missed something in this thread, but I don't see
what having symlink ownership buys you that is worth the extra
complexity that must be added to every program that attempts to grok the
filesystem.  The only real reason I've heard is disk quotas. But since
giving someone write access to a file or directory you own (sticky-bit
or not) automatically lets them do some things that count against your
quota and not theirs, I don't see this as significant.  Assuming
non-malicious behaviour, how many symlinks are created in directories
other by its owner?  Not many, I'll bet.  And, as I've mentioned,
malicious behaviour is possible anyway, regardless of the way symlinks
are handled.

To me, the KISS principle seems to dictate that the POSIX semantics are
a good thing.  And yes, the sticky bit hack needs a little more work,
but I think that it does anyway (i.e. I don't think you should be
allowed to hard link files you don't own into a sticky-bit accessed
directory).

--Lon Willett
  willett@math.utah.edu