Hard-link creation – Permissions?

Which permissions affect hard-link creation? Does file ownership itself matters?

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 it change anything?

I’ve tried to simulate this situation creating the following folder/file structure in a 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?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 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 http://kernel.opensuse.org/cgit/kernel/commit/?id=800179c9b8a1 [emphasis mine]:

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.

Method 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.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0