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?

dst
  • 141
  • 5
  • 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 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/fs/namei.c?id=refs/tags/v4.2.4#n977 should be fine. – Mingye Wang Oct 23 '15 at 23:32

1 Answers1

1

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

dst
  • 141
  • 5