Florian Weimer wrote:
> The fstat/fstat64 system call does not exist on arc and riscv/rv32.
> glibc tries to consolidate the implementations as far as possible, so if
> the kernel deprecates a system call and the replacement is already
> supported by all architectures, glibc uses that, rather than maintaing
> architecture-specific code to call the earliest possible implemented
> system call.
That explains it. So my patch calling the fstat64 syscall (fstat on 64-bit
platforms) in the fstatat handler should be fine on those platforms that
support the fstat(64) syscall.
But the thing is, fstatat is not really a newer version of fstat, it
unfortunately has very different security properties. fstat allows
retrieving the stat metadata only of already open files (if you know or
guess the fd). On the other hand, fstatat allows retrieving the stat
metadata of ANY file on the file system. It even accepts an absolute path as
the relative pathspec, in which case the fd is ignored entirely. (And I
guess it also allows directory traversal using "..", but that does not
matter anyway since it also accepts absolute paths to begin with.) And the
only way to distinguish the fstat case ("" pathspec) from the stat case
(absolute pathspec) is to actually look at the string, which cannot be done
in BPF.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
