Is this Ubuntu's mission?

I've just tested it. I have a seperate home partition., and I certainly can't create a hard link across partitions, I can create a soft link though. If I create a hard link within the same partition, I can delete the file and still access the file via the hard link.

Here's what I did.

As root, I copied a text file "qwerty" to /bin

cp /home/tracy/qwerty /bin

I then attempted to hard link to it as tracy in my home directory

tracy@annie:~$ ln /bin/qwerty /home/tracy/qwertylink ln: creating hard link `/home/tracy/qwertylink' => `/bin/qwerty': Invalid cross-device link tracy@annie:~$

and got the above error.

the following works fine

tracy@annie:~$ ln -s /bin/qwerty /home/tracy/qwertylink tracy@annie:~$ ls qwertylink qwertylink tracy@annie:~$

As root I can run

root@annie:/root# ln /bin/qwerty /root/qwertylink root@annie:/root# ls qwertylink qwertylink root@annie:/root#

and it works fine, creating ahardlink.

attempting the same thing into /home/tracy as root does not

root@annie:/root# ln /bin/qwerty /home/tracyr/qwertylinkr ln: creating hard link `/home/tracyr/qwertylinkr' => `/bin/qwerty': No such file or directory root@annie:/root#

So it is not possible to to create a hard link across filesystems.

now I can read the file /bin/qwerty from my home directory using the soft link, and I can read the file from the root user directory using the hard link.

But if I delete the file /bin/qwerty

root@annie:/bin# rm /bin/qwerty root@annie:/bin# ls qwerty ls: cannot access qwerty: No such file or directory root@annie:/bin#

and I attempt to read the file using the soft link in /home/tracy

tracy@annie:~$ cat qwertylink cat: qwertylink: No such file or directory tracy@annie:~$ ls qwertylink qwertylink

the link is still there. but the file it links to has gone.

but if I attempt the same things as root using the hardlink.

root@annie:/root# cat qwertylink chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{} root@annie:/root#

if displays the contents of the now non existent file.

root@annie:/root# ls /bin/qwerty ls: cannot access /bin/qwerty: No such file or directory root@annie:/root#

So as the article describes, the inode continues to exist for as long as the hardlink exists, even if you create a new copy of the file.

root@annie:/bin# cp /home/tracy/qwerty /bin root@annie:/bin# cat /bin/qwerty chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{} chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{}

root@annie:/root# cat qwertylink chapter{Bc,sfsd fsdfhjgdsjf gjhfdg}chapter{} root@annie:/root#

as you can see the hardlink in /root is still displaying the contents of the deleted file.

@tracyanne

Quoting: you missed the point. It wasn't about user writeable directories. It was about Inodes staying active while there is a hardlink to the file that has been deleted, and the danger that potentially creates when there is a a single filesystem. the point was it is possible to open up the system to an attacker, by not removing the hardlinks, not what an attacker might be able do once they are in.

Exactly, and that is why the real issue is user writable directories. If there are no user writable directories (edit: I mean in the same partition where suid programs reside) then an attacker cannot create hard-links in the first place to suid programs (though as I mentioned this point is likely to be moot if the system has been compromised) -- notice that for non-suid programs this does not matter in any case since a hard-link is functionally equivalent to a cp from attacker's POV. So what if an attacker makes a copy so that there is a supposedly vulnerable version still around? If someone were to make a copy of "apache", for example, it does not matter since the system will not be executing it during init etc -- it is completely a users binary which works such. Why do you think that a vulnerable version of "apache", for example, in user's home directory is a security hole? Of course, if the user were to run it explicitly then it might be a problem just like for any other vulnerable binaries in user's home. You are completely missing the point that the real problem is with suid programs. That is why the site makes an oblique reference to it in second recommendation "If they ran suid program scanners, they would have picked up this 'new' suid program" but does not make this point sufficiently clear. One of the recommendations that the site mentions is to have user writable directories /home, /tmp, /var/tmp on separate partitions, but as I mentioned a typical linux installation will have many more user writable directories and no distro I know of will offer separate partitions by default for all of those.

Quoting: Ubuntu attempts to mitigate this by providing the user with the ability to create soft links, the "Create a Link" in the right mouse click menu.

No no, this has got to do nothing with Ubuntu or soft-links -- see above.

Quoting: Yes there probably is something wrong that needs fixing, but "ln" is doing exactly what it was designed to do, so I can't see that there is a bug there.

If permission-wise "ln" were to behave like "cp" then users cannot create hard-links to programs having suid bit still set.

edit: Also notice that if one were to replace a file with a new version using normal "cp" then all hard-links will also point to the new version. The problem will only be if one were to first remove the old file and then add the new file in the same place. Apt and other installers will normally do the former so there is no vulnerability in any case in the normal course of actions.