Hard link creation - Permissions?

Question

Which permissions affect hard link creation? Does file ownership itself matter?

---

Suppose user alice wants to create a hard link to the file target.txt in a directory target-dir.

• Which permissions does alice need on both target.txt and target-dir?
• If target.txt is owned by user bill and target-dir is owned by user chad, does that change anything?

---

I've tried to simulate this situation by creating the following folder/file structure on an ext4 filesystem:

#> ls -lh . *
.:
drwxr-xr-x 2 bill bill 60 Oct  1 11:29 source-dir
drwxrwxrwx 2 chad chad 60 Oct  1 11:40 target-dir
source-dir:
-r--r--r-- 1 bill bill 0 Oct  1 11:29 target.txt
target-dir:
-rw-rw-r-- 1 alice alice 0 Oct  1 11:40 dummy

While alice can create a soft link to target.txt, she can't create a hard link:

#> ln source-dir/target.txt target-dir/
ln: failed to create hard link ‘target-dir/target.txt’ => ‘source-dir/target.txt’: Operation not permitted

If alice owns target.txt and no permissions are changed, the hard link succeeds. What am I missing here?

Answer 1

To create the hard link, alice will need write+execute permissions on target-dir on all cases. The permissions needed on target.txt will vary:

• If fs.protected_hardlinks = 1 then alice needs either ownership of target.txt or at least read+write permissions on it.
• If fs.protected_hardlinks = 0 then any set of permissions will do; Even 000 is okay.

---

This answer to a similar question had the missing piece of information to answer this question.

From this commit message (emphasis mine):

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.

Answer 2

alice needs at least read permission on target.txt and write+execute permission on target-dir.

Now, the permission structure works as a threefold separated set:

1. User permissions: apply to the user that owns the node.
2. Group permissions: apply to any user belonging to the group that owns the node.
3. Others' permissions: apply to any other user/group not owning the node.

Therefore, the ownership question affects only in which set of permissions the required permissions for alice are, being:

• If alice is the owner user, the required permissions must be in the "user" part.
• If alice is part of the group that owns it, the required permissions must be in the "group" part.
• If alice does not own it and is not part of the group that owns it, the required permissions must be in the "other" part.