Hard linking means that you can put the same Inode number into two different directories. Prior to Fedora 19, a normal user would be allowed to do something like:
> ln /etc/shadow ~/shadow
Even though the /etc/shadow is owned by root. Then if the user tricked an administrator into doing something like
# chown -R dwalsh:dwalsh ~
This would cause the /etc/shadow file to be owned by dwalsh.
Similarly in the past hackers have tricked privileged applications to follow hard and soft links, created in a user account to compromise the system.
Kees Cook wrote some patches for the linux kernel that allows distributions to disable this behaviour.
Here is Kees Description of the benefits of the patch:
This patch adds symlink and hardlink restrictions to the Linux VFS. Symlinks: A long-standing class of security issues is the symlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given symlink (i.e. a root process follows a symlink belonging to another user). For a likely incomplete list of hundreds of examples across the years, please see: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp The solution is to permit symlinks to only be followed when outside a sticky world-writable directory, or when the uid of the symlink and follower match, or when the directory owner matches the symlink's owner. <snip> Hardlinks: On systems that have user-writable directories on the same partition as system files, a long-standing class of security issues is the hardlink-based time-of-check-time-of-use race, most commonly seen in world-writable directories like /tmp. The common method of exploitation of this flaw is to cross privilege boundaries when following a given hardlink (i.e. a root process follows a hardlink created by another user). Additionally, an issue exists where users can "pin" a potentially vulnerable setuid/setgid file so that an administrator will not actually upgrade a system fully. The solution is to permit hardlinks to only be created when the user is already the existing file's owner, or if they already have read/write access to the existing file. Many Linux users are surprised when they learn they can link to files they have no access to, so this change appears to follow the doctrine of "least surprise". Additionally, this change does not violate POSIX, which states "the implementation may require that the calling process has permission to access the existing file". This change is known to break some implementations of the "at" daemon, though the version used by Fedora and Ubuntu has been fixed for a while. Otherwise, the change has been undisruptive while in use in Ubuntu for the last 1.5 years. <snip> This feature is turned on by default in /usr/lib/sysctl.d/50-default.conf in F19. grep fs /usr/lib/sysctl.d/50-default.conf fs.protected_hardlinks = 1 fs.protected_symlinks = 1 There was some concern that this could cause problems in applications that expect this behaviour, so it can be disabled. But overall, I think it is a positive feature for Fedora.