[PATCH v14 5/6] selftests: add openat2(2) selftests

2019-10-09 Thread Aleksa Sarai
Test all of the various openat2(2) flags. A small stress-test of a symlink-rename attack is included to show that the protections against ".."-based attacks are sufficient. The main things these self-tests are enforcing are: * The struct+usize ABI for openat2(2) and copy_struct_from_user() to

[PATCH v14 6/6] Documentation: path-lookup: mention LOOKUP_MAGICLINK_JUMPED

2019-10-09 Thread Aleksa Sarai
Now that we have a special flag to signify magic-link jumps, mention it within the path-lookup docs. And now that "magic link" is the correct term for nd_jump_link()-style symlinks, clean up references to this type of "symlink". Signed-off-by: Aleksa Sarai ---

[PATCH v14 4/6] open: introduce openat2(2) syscall

2019-10-09 Thread Aleksa Sarai
/* Background. */ For a very long time, extending openat(2) with new features has been incredibly frustrating. This stems from the fact that openat(2) is possibly the most famous counter-example to the mantra "don't silently accept garbage from userspace" -- it doesn't check whether unknown flags

[PATCH v14 3/6] namei: permit ".." resolution with LOOKUP_{IN_ROOT,BENEATH}

2019-10-09 Thread Aleksa Sarai
This patch allows for LOOKUP_BENEATH and LOOKUP_IN_ROOT to safely permit ".." resolution (in the case of LOOKUP_BENEATH the resolution will still fail if ".." resolution would resolve a path outside of the root -- while LOOKUP_IN_ROOT will chroot(2)-style scope it). Magic-link jumps are still

[PATCH v14 2/6] namei: LOOKUP_IN_ROOT: chroot-like path resolution

2019-10-09 Thread Aleksa Sarai
/* Background. */ Container runtimes or other administrative management processes will often interact with root filesystems while in the host mount namespace, because the cost of doing a chroot(2) on every operation is too prohibitive (especially in Go, which cannot safely use vfork). However, a

[PATCH v14 1/6] namei: O_BENEATH-style resolution restriction flags

2019-10-09 Thread Aleksa Sarai
/* Background. */ The need for some sort of control over VFS's path resolution (to avoid malicious paths resulting in inadvertent breakouts) has been a very long-standing desire of many userspace applications throughout the history of Unix. While some improvements have been made (such as

[PATCH v14 0/6] open: introduce openat2(2) syscall

2019-10-09 Thread Aleksa Sarai
This patchset is being developed here: Patch changelog: v14: * The magic-link changes (and O_EMPTYPATH) have been dropped from this series -- they will be developed and sent separately. The main reason is that we need to restrict

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

2019-10-09 Thread Robin Murphy
On 2019-10-08 9:38 am, Yunsheng Lin wrote: On 2019/9/25 18:41, Peter Zijlstra wrote: On Wed, Sep 25, 2019 at 05:14:20PM +0800, Yunsheng Lin wrote: From the discussion above, It seems making the node_to_cpumask_map() NUMA_NO_NODE aware is the most feasible way to move forwad. That's still