seccomp_api_get(3)

πŸ“¦
version 2.6.1 Β· 2 versions
, in alpine 3.22, alpine 3.23, alpine 3.24, arch rolling, debian trixie, fedora 43, fedora 44, nixpkgs unstable, opensuse-leap 16.0, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– seccomp_api_get β€” bestie edition πŸ’–

okay so real talk, this is seccomp_api_get and seccomp_api_set from the libseccomp docs, and they're literally just here to manage the libseccomp API level. that's the whole vibe. let's get into it 🫢


✨ NAME ✨

seccomp_api_get, seccomp_api_set β€” manage the libseccomp API level πŸ’…


🌸 SYNOPSIS 🌸

#include <seccomp.h>

const unsigned int seccomp_api_get(void);
int seccomp_api_set(unsigned int level);

and bestie, don't forget to link with -lseccomp or it's giving ✨ nothing ✨


πŸ¦‹ DESCRIPTION πŸ¦‹

so seccomp_api_get() returns an integer that represents the functionality β€” aka the "API level" β€” that your current running kernel is serving up. πŸ‘‘

and here's the thing you HAVE to know: even though you can call seccomp_api_get() as many times as your little heart desires, the kernel only gets probed the first time to see what functionality is supported. every call after that? it just returns a cached value. so it's giving fast, but it's also giving "we already checked, chill" 😌

now seccomp_api_set() lets callers force the API level to whatever value they hand over. but β€” and I cannot stress this enough β€” this is almost always a bad idea and use of this function is strongly discouraged. like, bestie, why would you do that. don't. 🚫

the different API level values are described below, and yes we're doing all of them:

  • 0 β€” Reserved value, not currently used. it's just sitting there, unbothered, unused πŸ’€
  • 1 β€” Base level support.
  • 2 β€” the SCMP_FLTATR_CTL_TSYNC filter attribute is supported, and libseccomp uses the seccomp(2) syscall to load the seccomp filter into the kernel. slay.
  • 3 β€” the SCMP_FLTATR_CTL_LOG filter attribute and the SCMP_ACT_LOG action are supported.
  • 4 β€” the SCMP_FLTATR_CTL_SSB filter attribute is supported.
  • 5 β€” the SCMP_ACT_NOTIFY action and the notify APIs are supported.
  • 6 β€” the simultaneous use of SCMP_FLTATR_CTL_TSYNC and the notify APIs are supported. teamwork makes the dream work fr fr 🀝
  • 7 β€” the SCMP_FLTATR_CTL_WAITKILL filter attribute is supported.

πŸŽ€ RETURN VALUE πŸŽ€

seccomp_api_get() returns an integer representing the supported API level. seccomp_api_set() returns zero on success, and negative values on failure. simple as that, no cap. ✨


🧚 EXAMPLES 🧚

here's the whole thing, character for character, because we do NOT paraphrase code in this house:

#include <seccomp.h>

int main(int argc, char *argv[])
{
     unsigned int api;

     api = seccomp_api_get();
     switch (api) {
     case 2:
          /* ... */
     default:
          /* ... */
     }

     return 0;

err:
     return 1;
}

⭐ NOTES ⭐

so while the seccomp filter can be generated independently of the kernel, kernel support is required to load and enforce the seccomp filter that libseccomp generates. you can build it anywhere, but you can't run it everywhere β€” vibe check passed only on supported kernels πŸ’€

the libseccomp project site, with more info and the source code repository, lives at https://github.com/seccomp/libseccomp. this tool, as well as the libseccomp library, is currently under development, so please report any bugs at the project site or directly to the author. be a good citizen, bestie 🫢


πŸ‘‘ AUTHOR πŸ‘‘

Paul Moore <paul@paul-moore.com>


and that's the whole page, periodt πŸ’… this was written by paul@paul-moore.com, dated 22 September 2022, and it lives in section 3 of the manual as seccomp_api_get(3) β€” courtesy of the libseccomp Documentation crew. mwah, go forth and check your API level πŸŒˆπŸ’–βœ¨