Permission to dereference/readlink /proc/PID/{cwd,exe,root} is
governed by a PTRACE_MODE_READ_FSCREDS ptrace access mode check.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Permission to access /proc/PID/{personality,stack,syscall} is
governed by a PTRACE_MODE_ATTACH_FSCREDS ptrace access mode check.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Permission to access /proc/PID/io is governed by
a PTRACE_MODE_READ_FSCREDS ptrace access mode check.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Permission to access /proc/PID/timerslack_ns is governed by
a PTRACE_MODE_ATTACH_FSCREDS ptrace access mode check.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Permission to access /proc/PID/{auxv,environ,wchan} is governed by
a PTRACE_MODE_READ_FSCREDS ptrace access mode check.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Permission to access /proc/PID/{maps,pagemap} is governed by a
PTRACE_MODE_READ_FSCREDS ptrace access mode check.
Permission to access /proc/PID/mem is governed by a
PTRACE_MODE_ATTACH_FSCREDS ptrace access mode check.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At least one bit must be set in the 'val3' mask supplied for the
FUTEX_WAIT_BITSET and FUTEX_WAKE_BITSET operations.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Darren Hart <dvhart@infradead.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Since Linux 4.5, FUTEX_WAIT also understands
FUTEX_CLOCK_REALTIME.
Reported-by: Darren Hart <dvhart@infradead.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
List the mount operations permitted by CAP_SYS_ADMIN in a
noninitial userns.
See https://bugzilla.kernel.org/show_bug.cgi?id=120671
Reported-by: Michał Zegan <webczat_200@poczta.onet.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Having privilege in a user NS only allows privileged
operations on resources governed by that user NS. Many
privileged operations relate to resources that have no
association with any namespace type, and only processes
with privilege in the initial user NS can perform those
operations.
See https://bugzilla.kernel.org/show_bug.cgi?id=120671
Reported-by: Michał Zegan <webczat_200@poczta.onet.pl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Add a concrete example of how the kernel checks capabilities in
an associated user namespace when a process attempts a privileged
operation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Avoid listing all namespace types in a couple of places,
since such a list is subject to bit rot as the number
of namespace types grows.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>