On 08/11/2019 15:33, Adhemerval Zanella wrote: > 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)?
