> its even more odd if you create the link in a directory which has the sticky bit set:
> ln /etc/shadow /tmp/myfile
> you can create that link, but you can't delete it afterwards (only root can do that)
Hmpf.
Actually I consider this to be an implementation bug of the directory sticky bit semantics. It should prevent from happening *any* changes to the directory involving names to inodes the subject process doesn't own. Most users just think about unlink(2)ing files, but it also prevents rename(2) from succeeding. Not blocking directory entry creation through link(2) in the first place thus should be considered incomplete implementation, or is there explicit standard language stating otherwise? I haven't read much beyond XPG4 ;)