From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id E9FF43858D39 for ; Fri, 1 Jul 2022 10:38:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E9FF43858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id CEC08302AB2C; Fri, 1 Jul 2022 12:38:12 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 76B254000C41; Fri, 1 Jul 2022 12:38:12 +0200 (CEST) Message-ID: Subject: Re: [PATCH 3/4] tst-pidfd.c: Test is UNSUPPORTED without PTRACE_MODE_ATTACH_REALCREDS From: Mark Wielaard To: Adhemerval Zanella Cc: Christian Brauner , Florian Weimer , libc-alpha@sourceware.org Date: Fri, 01 Jul 2022 12:38:12 +0200 In-Reply-To: <1C759F39-9598-44C7-9ED7-EC399A076180@linaro.org> References: <20220626205915.33201-1-mark@klomp.org> <20220626205915.33201-4-mark@klomp.org> <87h747nmud.fsf@mid.deneb.enyo.de> <874k06cq9t.fsf@oldenburg.str.redhat.com> <20220627115141.s4zjaac7ixceq7rs@wittgenstein> <87sfnq9nhj.fsf@oldenburg.str.redhat.com> <20220627150826.f4ezg3t4k7sy7kih@wittgenstein> <2A731D33-0573-40E6-B781-96C3693F169C@linaro.org> <927d12654e85b5352688fb9bfefda08171b73183.camel@klomp.org> <1C759F39-9598-44C7-9ED7-EC399A076180@linaro.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2022 10:38:15 -0000 Hi Adhemerval, On Mon, 2022-06-27 at 14:03 -0300, Adhemerval Zanella wrote: > > On 27 Jun 2022, at 13:48, Mark Wielaard 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. >=20 > At first I though it was the default kernel syscall code path (without > any security hardening or filtering) returning EPERM, but for this=20 > specific case it seems that an additional module that is return EPERM. >=20 > 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.=20 >=20 > 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= =20 > 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