On Mon, Feb 26, 2024 at 02:46:49PM +0100, Arnd Bergmann wrote: > On Mon, Feb 26, 2024, at 14:32, Christian Brauner wrote: > > On Mon, Feb 26, 2024 at 10:20:23AM +0100, Arnd Bergmann wrote: > >> On Mon, Feb 26, 2024, at 08:09, Xi Ruoyao wrote: > > > > What this tells me without knowing the exact reason is that they thought > > "Oh, if we just return ENOSYS then the workload or glibc will just > > always be able to fallback to fstat() or fstatat()". Which ultimately is > > the exact same thing that containers often assume. > > > > So really, just skipping on various system calls isn't going to work. > > You can't just implement new system calls and forget about the rest > > unless you know exactly what workloads your architecure will run on. > > > > Please implement fstat() or fstatat() and stop inventing hacks for > > statx() to make weird sandboxing rules work, please. > > Do you mean we should add fstat64_time64() for all architectures > then? Would use use the same structure layout as statx for this, > the 64-bit version of the 'struct stat' layout from > include/uapi/asm-generic/stat.h, or something new that solves > the same problems? > > I definitely don't want to see a new time32 API added to > mips64 and the 32-bit architectures, so the existing stat64 > interface won't work as a statx replacement. I don't specifically care but the same way you don't want to see newer time32 apis added to architectures I don't want to have hacks in our system calls that aren't even a clear solution to the problem outlined in this thread. Short of adding fstatx() the problem isn't solved by a new flag to statx() as explained in my other mails. But I'm probably missing something here because I find this notion of "design system calls for seccomp and the Chromium sandbox" to be an absurd notion and it makes me a bit impatient. And fwiw, once mseal() lands seccomp should be a lot easier to get deep argument inspection.
