Re: glibc in master is incompatible with systemd-nspawn

[Christian Brauner <christian.brauner@ubuntu.com>]

On November 8, 2019 5:19:47 PM GMT+01:00, Florian Weimer <fweimer@redhat.com> 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.