From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) by sourceware.org (Postfix) with ESMTPS id D2961386C5A2 for ; Mon, 27 Jun 2022 14:57:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D2961386C5A2 Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-101ec2d6087so13272761fac.3 for ; Mon, 27 Jun 2022 07:57:06 -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=u+bv8mzROdjYTJ9MfELe/SY76pCKfDeLlng0Tm4fq1k=; b=jt3s+uts9NagioWXOIpYjjPPzTyyrRyYhQ7biVj0YzYlDXgSupVaDVbhc6Pj1FoUyW B9EEchKF33wpqZQk+metQ1d9Tr2AvUe/tcdTnTDa+XkUXMkHXrK7LVfWG5I9zsZeA16D cfpW/YRfdBdIBFpEEPoiFHDI3fANPm/5A77iCsdr3S5ot5BGGgVpXlgzSLiyWXt7+Smu Vvzo6y8tddOzNS+YQ2wzaFsJblSD/yABEF/Jw94IbqBDNajr3XThKMZ2ho6UER2iyxx/ 3oKNkusbbK8AkHpp4gXqawGU76hAqUZLXejYXwVvBX5n+Ocn+nfmyRdnBdbyBthsG0fw qVcQ== X-Gm-Message-State: AJIora9Sq83/ieIXYJ4K1aNN6SwaGda011NX6k9YcRDFI3MMWCLjEQUp jgLZ+av+Bf3emeGHHeGDlqQ6JA== X-Google-Smtp-Source: AGRyM1tlY0Rh/eT1/BqQSkM08BXx3nXP4YdyqcDjMJ410DXwCHR3rEFDkv4hUeUfxetMBBi1v739Bw== X-Received: by 2002:a05:6870:d20f:b0:fe:110:267c with SMTP id g15-20020a056870d20f00b000fe0110267cmr10642749oac.250.1656341825972; Mon, 27 Jun 2022 07:57:05 -0700 (PDT) Received: from smtpclient.apple ([2804:431:c7ca:6d95:e1d4:5b7b:d7d4:ce7e]) by smtp.gmail.com with ESMTPSA id u5-20020a544385000000b003351d035f77sm5360823oiv.47.2022.06.27.07.57.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jun 2022 07:57:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 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: <87sfnq9nhj.fsf@oldenburg.str.redhat.com> Date: Mon, 27 Jun 2022 11:57:02 -0300 Cc: Christian Brauner , Mark Wielaard , libc-alpha@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Florian Weimer X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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 14:57:09 -0000 > On 27 Jun 2022, at 11:42, Florian Weimer via Libc-alpha = wrote: >=20 > * Christian Brauner: >=20 >> On Mon, Jun 27, 2022 at 01:14:06PM +0200, Florian Weimer via = Libc-alpha wrote: >>> * Mark Wielaard: >>>=20 >>>> Hi Florian, >>>>=20 >>>> On Sun, 2022-06-26 at 23:20 +0200, Florian Weimer wrote: >>>>> * Mark Wielaard: >>>>>=20 >>>>>> pidfd_getfd will fail with errno EPERM if the calling process did >>>>>> not >>>>>> have PTRACE_MODE_ATTACH_REALCREDS permissions. Use = FAIL_UNSUPPORTED >>>>>> in that case. >>>>>> --- >>>>>> sysdeps/unix/sysv/linux/tst-pidfd.c | 6 ++++-- >>>>>> 1 file changed, 4 insertions(+), 2 deletions(-) >>>>>>=20 >>>>>> diff --git a/sysdeps/unix/sysv/linux/tst-pidfd.c >>>>>> b/sysdeps/unix/sysv/linux/tst-pidfd.c >>>>>> index d93b6faa6f..28349b2f91 100644 >>>>>> --- a/sysdeps/unix/sysv/linux/tst-pidfd.c >>>>>> +++ b/sysdeps/unix/sysv/linux/tst-pidfd.c >>>>>> @@ -95,8 +95,10 @@ do_test (void) >>>>>> kernel has pidfd support that we can test. */ >>>>>> int r =3D pidfd_getfd (0, 0, 1); >>>>>> TEST_VERIFY_EXIT (r =3D=3D -1); >>>>>> - if (errno =3D=3D ENOSYS) >>>>>> - FAIL_UNSUPPORTED ("kernel does not support pidfd_getfd, >>>>>> skipping test"); >>>>>> + if (errno =3D=3D ENOSYS || errno =3D=3D EPERM) >>>>>> + FAIL_UNSUPPORTED ("kernel does not support pidfd_getfd," >>>>>> + " or we don't have >>>>>> PTRACE_MODE_ATTACH_REALCREDS" >>>>>> + " permissions, skipping test"); >>>>>> } >>>>>=20 >>>>> This also hints towards a broken seccomp filter. >>>>=20 >>>> pidfd_getfd is mentioned (and allowed) by the seccomp filter, but = the >>>> syscall also needs the process to have PTRACE_MODE_ATTACH_REALCREDS >>>> (which is really PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS). Which = it >>>> doesn't have. If the process doesn't then pidfd_getfd is defined as >>>> failing and setting errno to EPERM. >>>=20 >>> But what does it mean for a process to have PTRACE_MODE_REALCREDS? >>=20 >> #define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH | = PTRACE_MODE_REALCREDS) >>=20 >> PTRACE_MODE_ATTACH_REALCREDS means >> * PTRACE_MODE_REALCREDS which means cred->{g,u}id of the task are = used >> for permission checking: >>=20 >> So it's a bit nasty here but roughly if the ptracer's real {g,u}id = match >> the target task's (ptracee's) effective, save, and real [g,u]id then >> you'passed the first stage of permission checking. >>=20 >> If ptracer's [g,u]id aren't matching the ptracee's effective, saved, = and >> real [g,u]id the ptracer needs CAP_SYS_PTRACE in the ptracee's = userns. >> That will also get you past the first state of permission checking. >>=20 >> If both don't apply the request is denied with -EPERM. >=20 > I think this doesn't apply to the >=20 > pidfd_getfd (0, 0, 1) The init has PPID 0, which leads to the idea pid argument 0 is valid. So fdget won=E2=80=99t fail and EPERM will be returned by pidfd_pid. = Maybe use pidfd_getfd (TYPE_MAXIMUM (pid_t), 0, 1) instead to trigger a EBADF. >=20 > call because the arguments are invalid and we never get to the kernel > permission check. I thought this might be a self-get call, but that's > clearly not the case (0 does not refer to a process file descriptor). >=20 > So the comment should not mention PTRACE_MODE_ATTACH_REALCREDS at all > because it's really not relevant to the situation. This is just = another > case of broken seccomp filters. So the usual discussion whether we > should paper over that or not in the test suite applies here as well. >=20 > Thanks, > Florian