From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id 22F4D38312A1 for ; Mon, 27 Jun 2022 15:14:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 22F4D38312A1 Received: by mail-oi1-x236.google.com with SMTP id e131so13194182oif.13 for ; Mon, 27 Jun 2022 08:14:56 -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=JiLWZ6gUrMMBtK72IF0p22H8YrP+uU8qT91RiS7MQyY=; b=vey7t7zNcMJq0posyo0CnmBVFi/ly68OAkCuivz4eMOzFZJ0prgPW0LLgvkSKBU3Vu 7TaNrLgCrBT07CI79/+2zhyfBAbsWBA5rGNje5vzaqeRF6i8Vj7opxx3MuzsmPUHmO0c RUleZIsetBCC26fvSyUMR4NXxTJAkufpTzUeg7GH8Ydr/dQxos8yx0ehTIfVzPJA9vSm GNftFUTY+yzz+Z9TK0f6Ftn/OildNVPY5o8o9uNKfbA4GOfHBruS/Fx/9kIB/qFCLb/m fuwI9Ry9HwbS2PrHuA9uu/FeHO659BqlwknLwWIeqIxYZA2rmlGzSgvHeD+xa/iuazJT JtbA== X-Gm-Message-State: AJIora+7Bki30E9BXTYdErOrViYwyWeIY8QqYDNef6VAnGEKBMjs0vXR ba1Av2xzS/P9k0M9XPjiSer8oA== X-Google-Smtp-Source: AGRyM1ufaOXYFtBczzxN8tLoF2MGKRqbQy0I00ac12JgsRVQxkh1UuGJxDkGkaGz2j26/BhQWrZ/kA== X-Received: by 2002:a05:6808:b29:b0:335:37b6:3ce7 with SMTP id t9-20020a0568080b2900b0033537b63ce7mr10194060oij.104.1656342895218; Mon, 27 Jun 2022 08:14:55 -0700 (PDT) Received: from smtpclient.apple ([2804:431:c7ca:6d95:e1d4:5b7b:d7d4:ce7e]) by smtp.gmail.com with ESMTPSA id a2-20020a05680804c200b0032e3cca8561sm5516904oie.21.2022.06.27.08.14.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jun 2022 08:14:54 -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: <20220627150826.f4ezg3t4k7sy7kih@wittgenstein> Date: Mon, 27 Jun 2022 12:14:51 -0300 Cc: Florian Weimer , Mark Wielaard , libc-alpha@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A731D33-0573-40E6-B781-96C3693F169C@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> To: Christian Brauner X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-12.4 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 15:14:58 -0000 > On 27 Jun 2022, at 12:08, Christian Brauner = wrote: >=20 > On Mon, Jun 27, 2022 at 11:57:02AM -0300, Adhemerval Zanella wrote: >>=20 >>=20 >>> 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) >>=20 >> 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 > No, I don't think that's the case. > EPERM can only ever be returned from ptrace_may_access() in > pidfd_getfd() or if there's something like seccomp in the mix. >=20 > 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. >=20 > SYSCALL_DEFINE3(pidfd_getfd, int, pidfd, int, fd, unsigned int, flags) > 0 0 1 > { > struct pid *pid; > struct fd f; > int ret; >=20 > /* flags is currently unused - make sure it's unset */ > if (flags) // that's 1 so you should see -EINVAL > return -EINVAL; >=20 > f =3D fdget(pidfd); // That'll get you stdin most likely. > if (!f.file) > return -EBADF; >=20 > pid =3D pidfd_pid(f.file); // That would give you -EBADF see [1] > if (IS_ERR(pid)) > ret =3D PTR_ERR(pid); > else > ret =3D pidfd_getfd(pid, fd); >=20 > fdput(f); > return ret; > } >=20 > [1]: >=20 > struct pid *pidfd_pid(const struct file *file) > { > if (file->f_op =3D=3D &pidfd_fops) // stdin is no pidfd and thus = doesn't have pidfd_fops > return file->private_data; >=20 > return ERR_PTR(-EBADF); // that's what you'd see for stdin > }