Hard-link creation - Permissions?

Question

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?

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

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

Comments

[gcscaglia]

I thought so as well. But in my situation target.txt has 444 permissions and target-dir has 777 permissions yet I'm unable to create a hard-link unless I do so as root or I own the file I'm linking to. Oddly enough, a soft-link will work as you describe.

[Octavian Tarasa]

That information would be useful to have in the question itself, I recommend you to update. Oddly enough I didn't think of it before... but does the file system where you are working support Unix-like ownerships/permissions, to start with?

[gcscaglia]

Yes it does, it is an out-of-the-box ext4 on a fedora 21 system; The link do works when I'm the owner of the file.

[Arda]

Thanks! This is what I've been struggling for a day on Debian 9!

[Michael]

Why would I get "operation not permitted" even when I have rwx perms on the dir and rw perms on the file?

[Admin]

Oddly enough, a soft-link will work as you describe. A soft-link is nothing more than a file of a special type with some text. The text is the path pointed to by the link. You can put arbitrary text there: ln -s 'this is my text' my-soft-link works just fine. Since it's just a file with a special type, you only need write permission to the directory where you create the soft-link.