aboutsummaryrefslogtreecommitdiffstats
path: root/tools/testing/selftests/openat2/helpers.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2020-02-13selftests: openat2: fix build error on newer glibcAleksa Sarai1-1/+1
It appears that newer glibcs check that openat(O_CREAT) was provided a fourth argument (rather than passing garbage), resulting in the following build error: > In file included from /usr/include/fcntl.h:301, > from helpers.c:9: > In function 'openat', > inlined from 'touchat' at helpers.c:49:11: > /usr/include/x86_64-linux-gnu/bits/fcntl2.h:126:4: error: call to > '__openat_missing_mode' declared with attribute error: openat with O_CREAT > or O_TMPFILE in third argument needs 4 arguments > 126 | __openat_missing_mode (); > | ^~~~~~~~~~~~~~~~~~~~~~~~ Reported-by: Shuah Khan <shuah@kernel.org> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2020-01-18selftests: add openat2(2) selftestsAleksa Sarai1-0/+109
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 ensure that upgrades will be handled gracefully (in addition, ensuring that misaligned structures are also handled correctly). * The -EINVAL checks for openat2(2) are all correctly handled to avoid userspace passing unknown or conflicting flag sets (most importantly, ensuring that invalid flag combinations are checked). * All of the RESOLVE_* semantics (including errno values) are correctly handled with various combinations of paths and flags. * RESOLVE_IN_ROOT correctly protects against the symlink rename(2) attack that has been responsible for several CVEs (and likely will be responsible for several more). Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Aleksa Sarai <cyphar@cyphar.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>