This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc in master is incompatible with systemd-nspawn
* 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