>>on Linux it is possible for any user to create a hard link to a file belonging >>to another user. > >Only if they can write to some directory on the same partition. > >>Furthermore, users can even create links to a setuid binary. > >Only if it's on the same partition. This is just one of a huge number of >reasons you shouldn't allow users to write to your root or /usr partitions. > >I think that your observation of the ability to keep a security hole open is >very interesting, but, fortunately, it should be moot. Many (older) recipies for replacing set-uid binaries consisted of: mv /usr/bin/buggy /usr/bin/buggy.old chmod 0 /usr/bin/buggy.old so it's certainly possible to work around that problem. >I think that this is too drastic a change to the semantics of the unix >filesystem. Except for the kludge around the sticky bit, nothing about >creation and deletion of files (links) depends upon the permissions on the >file itself, just on the enclosing directory. But it can't be denied that hard links to files one doesn't own pose some interesting challenges; not just in the scope of quotas but also when it comes to actions users cannot undo (such as making many links to files belonging to other users in /tmp) >>If you can check whether this problem also exists on other unix-like >>operating systems, please post the results. > >It certainly does. This is part of the original design of the unix >filesystem. Creating a link requires write access to the directory you're >creating it in, not to the file you're linking to. > > >I think that if a user creates a bunch of hard links to someone else's >temporary files, the evidence should point to the original user, on a typical >well-maintained unix system. The link to setuid programs is more of concern >except that it won't be able to happen unless you have setuid-root programs >in a home directory partition, which sounds bad anyway. And you can easily work around it when replacing executables. Casper
