[PATCHv3] tst-pidfd.c: UNSUPPORTED if we get EPERM on pidfd_open or pidfd_getfd

[Mark Wielaard]

Hi Adhemerval,

On Mon, 2022-07-04 at 23:39 -0300, Adhemerval Zanella wrote:
> > On 4 Jul 2022, at 18:20, Mark Wielaard <mark@klomp.org> wrote:
> > On Mon, Jul 04, 2022 at 04:46:58PM -0300, Adhemerval Zanella wrote:
> > point of the check is that we cannot run the test if we get an EPERM
> > at this point. pidfd_getfd can fail with EPERM for various reasons (an
> > LSM module, a ptrace mode check, a [broken] seccomp filter). In all
> > cases we simply record the issue and mark the testcase as UNSUPPORTED.
> 
> No, in glibc we assume that if the syscall is not implemented by the kernel
> is should return ENOSYS, not EPERM.  If kernel is doing otherwise it is
> returning bogus values and we moved away to either try to emulate fallbacks
> it or handle it (just check the issues we had with clone3).

I see where you are coming from, but I don't think these situations are
comparable. All we do here is check the test environment, not implement
some fallback mechanism.

That said, I think I went overboard wanting to catch all possible EPERM
causes. And I can see that doing this as a "pre-check" which also
covers the ENOSYS case might be confusing. And also not really
necessary if you don't like that.

I'll post a v4 that drops this early-check and also on the pid_fdopen
calls. Because that really isn't the point here. Just checking that
that a pidfd_getfd with valid pidfd and remotefd gets an EPERM is all
that is really needed. And can really be rejected by the ptrace/lsm
checks without caring whether there are also syscall filters that might
also reject it in other cases.

> Sorry, but you really need to sort this out on your syscall filtering
> mechanism. 

I don't think the syscall filtering mechanism is doing anything wrong
here, but I can see why you say that given I added those extra EPERM
checks where you don't want to see them.

BTW. It isn't "my" syscall filtering mechanism, it really is the
standard one used by docker. Which you will probably encounter in a lot
of container environments. The idea is that we we can use a buildbot
running tests in containers for all glibc developers to do pre-commit
checks and to test patchwork patches with the try-bot (and currently
for all commits to the main branch): 
https://builder.sourceware.org/buildbot/#/builders?tags=glibc

All the configuration is in git:
https://sourceware.org/git/builder.git (see SETUP and README_workers)
If you really think it was setup wrongly (which is certainly a
possibility) please do suggest a patch so we can run the containers in
a better way.

Thanks,

Mark