* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.