Example script:#!/bin/sh -e sudo useradd -m user_asudo useradd -m user_b -g user_asudo chmod g+w /home/user_aset +esudo su user_a <<EOFcdumask 027>> file_a >> file_b>> file_cls -l file_*EOFsudo su user_b <<EOFcdumask 000rm -f file_*ls -l ~user_a/set -xmv ~user_a/file_a .cp ~user_a/file_b .ln ~user_a/file_c .set +xls -l ~/EOFsudo userdel  -r user_bsudo userdel  -r user_aOutput:-rw-r----- 1 user_a user_a 0 Jul 11 12:26 file_a-rw-r----- 1 user_a user_a 0 Jul 11 12:26 file_b-rw-r----- 1 user_a user_a 0 Jul 11 12:26 file_ctotal 0-rw-r----- 1 user_a user_a 0 Jul 11 12:26 file_a-rw-r----- 1 user_a user_a 0 Jul 11 12:26 file_b-rw-r----- 1 user_a user_a 0 Jul 11 12:26 file_c+ mv /home/user_a/file_a .+ cp /home/user_a/file_b .+ ln /home/user_a/file_c .ln: failed to create hard link ./file_c => /home/user_a/file_c: Operation not permitted+ set +xtotal 0-rw-r----- 1 user_a user_a 0 Jul 11 12:26 file_a-rw-r----- 1 user_b user_a 0 Jul 11 12:26 file_buserdel: user_b mail spool (/var/mail/user_b) not founduserdel: user_a mail spool (/var/mail/user_a) not found
Why can I not hardlink to a file I don't own even though I can move it?
linux;files;permissions;hard link;move
Which system are you running? On Linux, that behaviour is configurable, through /proc/sys/fs/protected_hardlinks (or sysctl fs.protected_hardlinks).The behaviour is described in proc(5):/proc/sys/fs/protected_hardlinks (since Linux 3.6)                When the value in this file is 0, no restrictions are placed                on the creation of hard links (i.e., this is the historical                behavior before Linux 3.6).  When the value in this file is 1,                a hard link can be created to a target file only if one of the                following conditions is true:The calling process has the CAP_FOWNER capability ...The filesystem UID of the process creating the link matches               the owner (UID) of the target file ...All of the following conditions are true:    the target is a regular file;the target file does not have its set-user-ID mode bit               enabled;the target file does not have both its set-group-ID and               group-executable mode bits enabled; andthe caller has permission to read and write the target               file (either via the file's permissions mask or because               it has suitable capabilities).And the rationale for that should be clear:The default value in this file is 0.  Setting the value to 1                prevents a longstanding class of security issues caused by                hard-link-based time-of-check, time-of-use races, most                commonly seen in world-writable directories such as /tmp.On Debian systems protected_hardlinks and the similar protected_symlinks default to one, so making a link without write access to the file doesn't work:$ ls -ld . ./foodrwxrwxr-x 2 root itvirta 4096 Jul 11 16:43 ./-rw-r--r-- 1 root root       4 Jul 11 16:43 ./foo$ mv foo bar$ ln bar bar2ln: failed to create hard link 'bar2' => 'bar': Operation not permittedSetting protected_hardlinks to zero lifts the restriction:# echo 0 >  /proc/sys/fs/protected_hardlinks $ ln bar bar2$ ls -l bar bar2-rw-r--r-- 2 root root 4 Jul 11 16:43 bar-rw-r--r-- 2 root root 4 Jul 11 16:43 bar2