* Szabolcs Nagy: > it's of course broken whenever the application is > run on a newer kernel+libc than what was used for > creating the filter, may be the seccomp manual should > warn against the use of EPERM (there is already a > caveats section)? On this topic (ENOSYS vs PERM), I wrote earlier today: | They serve different purposes. EPERM is appropriate if you want things | to fail (so that applications break), ENOSYS is appropriate if you | want to trigger fallback (like utimensat_time64 → utime) or just | disable the feature (because the application assumes the kernel is too | old to support it). For a generic container runtime, there either have | to be no filters by default (my preference), or filters for unknown | system calls need to return ENOSYS. Everything else will break too | many applications. | | If you have specific knowledge of the system call, you can return | EPERM instead in a few cases (e.g. for clock_settime). But that's not | really possible for an unknown system call. <https://bugzilla.redhat.com/show_bug.cgi?id=1769299> I don't know how controversial this position is. People seem rather opinionated about EPERM. Thanks, Florian
