Re: [PATCH 3/4] tst-pidfd.c: Test is UNSUPPORTED without PTRACE_MODE_ATTACH_REALCREDS

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

> On 27 Jun 2022, at 13:48, Mark Wielaard <mark@klomp.org> wrote:
> 
> Hi Adhemerval,
> 
> On Mon, 2022-06-27 at 12:14 -0300, Adhemerval Zanella wrote:
>>> You should see EINVAL, I think.
>> 
>> Yeah, I forgot about the invalid flag argument.  So it does seems a
>> seccomp issue and I am not sure sure if we should paper over it on
>> glibc test.
> 
> I don't think it is papering over the issue. We do detect the EPERM and
> record it as an environment that is UNSUPPORTED. Which is imho a better
> state than still trying to test and then FAILing the testcase.

At first I though it was the default kernel syscall code path (without
any security hardening or filtering) returning EPERM, but for this 
specific case it seems that an additional module that is return EPERM.

In this specific environment, how can one test that the syscall is not
implemented (ENOSYS) if passing invalid parameters always result in
EPERM? The different semantic whether filtering is present or not is
troublesome and at least on libc.so we do not try fallback. 

although it has caused a lot of issue on older containers (for instance
when glibc started to use clone3), I still think the correct interface 
here is indeed returning ENOSYS and a value different than this is
a potential failure.

What I would expect is to actually handle EPERM on the pidfd_open
at line 118, where it is valid call that might be filtered out.

> 
> Note that in the buildbot the test results and out files are put into
> the bunsendb so that you can easily see why a particular test was
> UNSUPPORTED (or why it FAILED).
> 
> We might not like that there are execution environments where some
> syscalls return EPERM, but (sadly) they exist and handling and
> recording that in the test (instead of simply failing) seems the best
> way to handle that.
> 
> It also makes sure we have a zero-FAIL testsuite, which is really
> useful.
> 
> Cheers,
> 
> Mark