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

That was my initial reaction too, but then it occurred to me that
"mkdir /tmp/$USER.tmp; cd/tmp/$USER.tmp" before extracting the tarfile
solves the problem.  (It also avoids cluttering up /tmp's top-level
with an extracted package.)

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

Sure, and the proposed fix would allow you to.  Of course, that's
assuming your proposed link target is on the same filesystem as /tmp.

> However, I think that ditching the new semantics is a good idea, [...]

As far as I can see, the _only_ reason for not going back to the old
way is the (reported) POSIX spec that almost all syscalls follow
terminal symlinks.  If this is in fact true, we must choose: we can
roll back symlink semantics, at the price of being not fully POSIX
compliant, or we can put up with obnoxious symlinks for the sake of
POSIX, or we can add lchown(), lutimes(), and friends.

Personally, I'd pick the first of the three.  I'd even more prefer a
kernel config option, of course, but not having looked at it, I don't
know how much complexity it would introduce and thus I'm not sure
whether it's really worthwhile.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu