Re: [PATCH] proc: protect ptrace_may_access() with exec_update_lock (part 1)

[Magnus Lindholm]

Hi,

while testing my Alpha generic-entry series on top of v7.2-rc1, I noticed
that several strace --pidns-translation tests started failing. The same
generic-entry series on top of v7.1-rc1 passes these tests.

I bisected the regression between v7.1-rc1 and v7.2-rc1, always applying
the same generic-entry series before testing, and the first bad commit is:

  6650527444dadc63d84aa939d14ecba4fadb2f69
  proc: protect ptrace_may_access() with exec_update_lock (part 1)

Examples of failing strace tests include:

  signal_receive--pidns-translation.gen.test
  so_peercred--pidns-translation.gen.test
  tgkill--pidns-translation.gen.test
  tkill--pidns-translation.gen.test
  fcntl--pidns-translation.gen.test
  xet_robust_list--pidns-translation.gen.test
  xetpgid--pidns-translation.gen.test
  xetpriority--pidns-translation.gen.test

One simple reproducer is:

  cd strace/tests
  ./xetpgid--pidns-translation.gen.test

The failure looks like this:

  ../../src/strace: NS_* ioctl commands are not supported by the kernel

and the decoded output lacks the expected pidns translation comments, e.g.:

  - getpgid(2 /* 6 in strace's PID NS */) = 0
  + getpgid(2) = 0

Looking at the patch, the relevant part seems to be the change in
fs/proc/namespaces.c: proc_ns_get_link() and proc_ns_readlink() now take
task->signal->exec_update_lock around the ptrace_may_access() check and
namespace link/readlink handling. strace's --decode-pids=pidns code appears
to rely on accessing /proc/<pid>/ns/pid for short-lived tracees in a nested
PID namespace, so this looks like a plausible connection to the failure.

The kernel has the relevant namespace options enabled:

  CONFIG_NAMESPACES=y
  CONFIG_USER_NS=y
  CONFIG_PID_NS=y
  CONFIG_CHECKPOINT_RESTORE=y
  CONFIG_PROC_FS=y

I also tested the basic nsfs ioctls with a small standalone program, both
outside and inside "unshare -Urpf", and NS_GET_NSTYPE,
NS_GET_PID_IN_PIDNS and NS_GET_PID_FROM_PIDNS all work there. So the failure
does not look like missing namespace support or a simple ioctl-number issue;
it seems specific to the proc/ns access pattern used by strace's pidns
translation code.

#regzbot introduced: 6650527444dadc63d84aa939d14ecba4fadb2f69

Thanks,
Magnus