bug#56359: seccomp test failures on RHEL 9.0

[Philipp Stephani <p.stephani2@gmail.com>]

Am Di., 11. Okt. 2022 um 21:47 Uhr schrieb Lars Ingebrigtsen <larsi@gnus.org>:
>
> Paul Eggert <eggert@cs.ucla.edu> writes:
>
> > My "fix" involved allowing all uses of clone3, which (as Philipp noted
> > in August) is problematic. I'm not sure what's being tested for, but
> > if clone3 lets you evade the checks then the test is arguably more
> > trouble than it's worth. Would marking it as :unstable lessen the
> > number of false alarms we're getting? If not, perhaps we should remove
> > it or mark it as :dont-use-unless-you-know-what-youre-doing or
> > whatever.
>
> And pidfd_open also sounds like a non-safe call (without looking at it
> closely).
>
> Skimming the tests, they seem to test pretty basic functionality in the
> seccomp area -- that is, without allowing pidfd_open/clone3, nothing
> will be able to run using the seccomp functionality.  But since those
> are somewhat unsafe, then...  what's the point?

Neither pidfd_open nor clone3 are "unsafe". The concern is that clone3
might expand its functionality to eventually allow unsafe operations
like opening network sockets, and with its interface there's no way
for a seccomp filter to prevent that. One option might be to have
clone3 return ENOSYS, if the caller falls back to clone in that case.