On November 8, 2019 5:19:47 PM GMT+01:00, Florian Weimer <fweimer@xxxxxxxxxx> wrote: >* 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 Fwiw, with LXC and LXD we use ENOSYS. I chatted with Lennart about this a few minutes ago.
