Florian Weimer wrote: > Right, and the glibc 2.33 versions all call fstatat64 in the end (system > call number 0x106).
That would be: #if !defined(__NR_newfstatat) #define __NR_newfstatat 262 #endif from: https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/system_headers/x86_64_linux_syscalls.h > The older x versions call the earlier system calls > (numbers 4, 5, 6) And these are defined as: #if !defined(__NR_stat) #define __NR_stat 4 #endif #if !defined(__NR_fstat) #define __NR_fstat 5 #endif #if !defined(__NR_lstat) #define __NR_lstat 6 #endif I see that the sandbox is treating __NR_newfstatat as IsFileSystem, like __NR_stat and __NR_lstat, whereas __NR_fstat is under IsAllowedFileSystemAccessViaFd. So the issue is that everything now calls the same syscall under the hood, so the sandbox can no longer distinguish the two access types just by looking at the syscall ID. The baseline policy disallows everything under IsFileSystem and allows only IsAllowedFileSystemAccessViaFd: https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc (i.e., __NR_fstat is allowed, whereas __NR_stat, __NR_lstat, and __NR_newfstatat are not). It looks like it needs to restrict the arguments to __NR_newfstatat (to an empty path and the AT_EMPTYPATH flag) instead of rejecting it outright, so that fstat keeps working, see: https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fstat.c;h=dc117361ffe7064be7c6746465388803e203adcf;hb=HEAD Kevin Kofler _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
