From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) by sourceware.org (Postfix) with ESMTPS id 4AA873858427 for ; Mon, 27 Jun 2022 17:03:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4AA873858427 Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-101ab23ff3fso13753734fac.1 for ; Mon, 27 Jun 2022 10:03:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RjLpQgve1uQlfj+aQMm6MC+aXJvpM7CKCZV30SmPVEM=; b=erAQpP+JCTimWXS2x88al4lnhbK6ocWxJocjKtMHAWgEZV3bxbXBFlzpXM5PB7BU/0 c5+xFtFIbMDp1w2riFMQ4Y82s/DEL1+FD+RuO1RtdQLtFYudgTjWvfk8wlY/tgmChVhC zSgorrHLcmqTnlBy6Cr9RLk7Oz+HdVY4NO2yP2zeAn6qMRqfWlHVNCSTQQ9dnX/VQYQy 13jBu4FRQKVvE7b+cAg3sABcmj5RWpI0Y870gamiPf1XqPxI5ca96D+tCsodTDA4wZ87 fAABbv9D+/dguZtx9v1QwvxX3AFBafn9/KZAAFD+Kv+7CIMTUb0nvkpU3aIfDrjgYAH/ Jfpw== X-Gm-Message-State: AJIora98ZHZP7+nEYhvtsAc6p5O5R3BeFPIv5kbTHZN+0TOetUas4F1F OEO9UW1Fl6MBD42dYQB9hW+8Z/IV3qnZl3Is X-Google-Smtp-Source: AGRyM1vlLNLZeaEU9Cb5P3Q8LvSXM9yaTqm+URwE6d+UejwuOwxc/lbEqogBcJo/q+/FD6SPrsUFBw== X-Received: by 2002:a05:6870:8311:b0:100:ef5f:77b6 with SMTP id p17-20020a056870831100b00100ef5f77b6mr11129919oae.157.1656349388434; Mon, 27 Jun 2022 10:03:08 -0700 (PDT) Received: from smtpclient.apple ([2804:431:c7ca:6d95:e1d4:5b7b:d7d4:ce7e]) by smtp.gmail.com with ESMTPSA id bg40-20020a05680817a800b0032c14a97747sm5692184oib.56.2022.06.27.10.03.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jun 2022 10:03:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: [PATCH 3/4] tst-pidfd.c: Test is UNSUPPORTED without PTRACE_MODE_ATTACH_REALCREDS From: Adhemerval Zanella In-Reply-To: <927d12654e85b5352688fb9bfefda08171b73183.camel@klomp.org> Date: Mon, 27 Jun 2022 14:03:04 -0300 Cc: Christian Brauner , Florian Weimer , libc-alpha@sourceware.org Content-Transfer-Encoding: 7bit Message-Id: <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> To: Mark Wielaard X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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: Mon, 27 Jun 2022 17:03:10 -0000 > On 27 Jun 2022, at 13:48, Mark Wielaard 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