BUG: add support for the faccessat2() syscall

[trofi]

In pax-utils (libseccomp user) we recently discovered that glibc-2.33 started using faccessat2 syscall: https://bugs.gentoo.org/768435

Would it be reasonable to add it to list of known syscalls it seccomp-syscalls.h?

Thanks!

[pcmoore]

Hi @trofi, what version of libseccomp are you using? I ask because the faccessat2() syscall has been defined in libseccomp since v2.5.0; if you are using an older version of libseccomp you are strongly encouraged to upgrade to the latest v2.5.x release (currently that is v2.5.1).

Here is a the definition in the v2.5.0 release tag (HINT: the syscalls.csv file is searchable in GitHub):

• https://github.com/seccomp/libseccomp/blob/v2.5.0/src/syscalls.csv#L63

[trofi]

Oh, interesting. I'm using release 2.5.1, but my /usr/include/seccomp-syscalls.h doe not seem to have needed syscalls available for use with SCMP_SYS(faccessat2) macro:

$ cat a.c
#include <seccomp.h>

int base_syscalls[] = {
    SCMP_SYS(faccessat),  // ok
    SCMP_SYS(faccessat2), // fails
};
$ gcc -c a.c
In file included from a.c:1:
a.c:5:5: error: '__SNR_faccessat2' undeclared here (not in a function)
    5 |     SCMP_SYS(faccessat2), // fails
      |     ^~~~~~~~

$ fgrep faccess /usr/include/seccomp-syscalls.h
#define __SNR_faccessat                 __NR_faccessat

Could it be that release tarball (and git tree) contains pregenerated list of syscalls from that file that was not updated after csv change?

[drakenclimber]

Good find. Looks like we're missing the appropriate #defines for faccessat2 in seccomp-syscalls.h

[pcmoore]

Ha, yes, it looks like you guys are right! I went ahead and added this to the v2.5.2 milestone so it should be in the next v2.5.x maintenance release.

I also created issue #315 to have the src/arch-syscall-check.c test for this so hopefully we can catch these during development in the future.

[pcmoore]

This should be resolve with PR #322 so I'm going to close this out; the fix will be in the next v2.5.x release.