3

Consider the following transcript of a user-namespaced shell running with root privileges (UID 0 within the namespace, unprivileged outside):

# cat /proc/$$/status | grep CapEff
CapEff: 0000003cfdfeffff
# ls -al
total 8
drwxrwxrwx  2 root   root   4096 Sep 16 22:09 .
drwxr-xr-x 21 root   root   4096 Sep 16 22:08 ..
-rwSr--r--  1 nobody nobody    0 Sep 16 22:09 file
# ln file link
ln: failed to create hard link 'link' => 'file': Operation not permitted
# su nobody -s /bin/bash -c "ln file link"
# ls -al
total 8
drwxrwxrwx  2 root   root   4096 Sep 16 22:11 .
drwxr-xr-x 21 root   root   4096 Sep 16 22:08 ..
-rwSr--r--  2 nobody nobody    0 Sep 16 22:09 file
-rwSr--r--  2 nobody nobody    0 Sep 16 22:09 link

Apparently the process has the CAP_FOWNER permission (0x8) and thus should be able to hardlink to arbitrary files. However, it failes to link the SUID'd test file owned by nobody. There is nothing preventing the process from switching to nobody and then linking the file, thus the parent namespace does not seem to be the issue.

Why can't the namespaced UID 0 process hardlink link to file without switching its UID?

  • As I'm unsure about GPL compatibility of CC-BY-SA, I did not include any kernel sources in the question; I assumed FOWNER should be sufficient from looking at fs/namei.c, the check in static int may_linkat should succeed if capable(CAP_FOWNER) is true. – dst Sep 16 '15 at 20:25
  • Adding a link to git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/… should be fine. – Arthur2e5 Oct 23 '15 at 23:32
0

The behavior described in the question was a bug, which has been fixed in the upcoming Linux 4.4.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.