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

[Mark Wielaard <mark@klomp.org>]

Hi Adhemerval,

On Mon, 2022-06-27 at 14:03 -0300, Adhemerval Zanella wrote:
> > On 27 Jun 2022, at 13:48, Mark Wielaard <mark@klomp.org> wrote:
> > 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.

Completely agreed. If you cannot make a difference between ENOSYS or
EOERM errors it is a pain/impossible to create (or test) the usage of
such a system call. That is why the pathc simply detects the issue,
flags it and doesn't try to run the testcase because that is impossible
to do correctly in that environment.

> 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.

Good point. I will add that in a v3.

Thanks,

Mark