glibc in master is incompatible with systemd-nspawn
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Adhemerval Zanella
Since when systemd-nspawn has this behaviour? What was the rationale to use EPERM instead of ENOSYS? IMHO ENOSYS it the expected error in this case, since filtering is essentially blocking the syscall usage altogether.
docker does the same, but at least you can disable it with --security-opt seccomp:unconfined
i think the original sin was committed by chromium which uses EPERM in its sandbox.
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)?
* Szabolcs Nagy:
Quoted 5 lines
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
Quoted 26 lines · Florian Weimer
* Szabolcs Nagy:
Quoted 5 lines
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.
Quoted 7 lines
<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.