* Re: glibc in master is incompatible with systemd-nspawn [not found] ` <c4001320-2d3f-9523-c93f-60f799545654@linaro.org> @ 2019-11-08 16:01 ` Szabolcs Nagy 2019-11-08 16:19 ` Florian Weimer 0 siblings, 1 reply; 3+ messages in thread From: Szabolcs Nagy @ 2019-11-08 16:01 UTC (permalink / raw) To: Adhemerval Zanella, libc-alpha; +Cc: nd, linux-man 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)? ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: glibc in master is incompatible with systemd-nspawn 2019-11-08 16:01 ` glibc in master is incompatible with systemd-nspawn Szabolcs Nagy @ 2019-11-08 16:19 ` Florian Weimer 2019-11-08 16:23 ` Christian Brauner 0 siblings, 1 reply; 3+ messages in thread From: Florian Weimer @ 2019-11-08 16:19 UTC (permalink / raw) To: Szabolcs Nagy; +Cc: Adhemerval Zanella, libc-alpha, nd, linux-man * 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: glibc in master is incompatible with systemd-nspawn 2019-11-08 16:19 ` Florian Weimer @ 2019-11-08 16:23 ` Christian Brauner 0 siblings, 0 replies; 3+ messages in thread From: Christian Brauner @ 2019-11-08 16:23 UTC (permalink / raw) To: libc-alpha, Florian Weimer, Szabolcs Nagy Cc: Adhemerval Zanella, libc-alpha, nd, linux-man 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-11-08 16:23 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <87k18a62xe.fsf@oldenburg2.str.redhat.com> [not found] ` <20191108141149.GB20533@altlinux.org> [not found] ` <87v9ru1l6d.fsf@oldenburg2.str.redhat.com> [not found] ` <c4001320-2d3f-9523-c93f-60f799545654@linaro.org> 2019-11-08 16:01 ` glibc in master is incompatible with systemd-nspawn Szabolcs Nagy 2019-11-08 16:19 ` Florian Weimer 2019-11-08 16:23 ` Christian Brauner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).