From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id DA423386C598 for ; Mon, 27 Jun 2022 14:42:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DA423386C598 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-53-pRVzynAUP_yKV8n6zEwEWg-1; Mon, 27 Jun 2022 10:42:34 -0400 X-MC-Unique: pRVzynAUP_yKV8n6zEwEWg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0A7D23C11062; Mon, 27 Jun 2022 14:42:34 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.138]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 53F17C2810D; Mon, 27 Jun 2022 14:42:33 +0000 (UTC) From: Florian Weimer To: Christian Brauner Cc: Mark Wielaard , libc-alpha@sourceware.org Subject: Re: [PATCH 3/4] tst-pidfd.c: Test is UNSUPPORTED without PTRACE_MODE_ATTACH_REALCREDS 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> Date: Mon, 27 Jun 2022 16:42:32 +0200 In-Reply-To: <20220627115141.s4zjaac7ixceq7rs@wittgenstein> (Christian Brauner's message of "Mon, 27 Jun 2022 13:51:41 +0200") Message-ID: <87sfnq9nhj.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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:42:39 -0000 * Christian Brauner: > On Mon, Jun 27, 2022 at 01:14:06PM +0200, Florian Weimer via Libc-alpha wrote: >> * Mark Wielaard: >> >> > Hi Florian, >> > >> > On Sun, 2022-06-26 at 23:20 +0200, Florian Weimer wrote: >> >> * Mark Wielaard: >> >> >> >> > 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(-) >> >> > >> >> > 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 = pidfd_getfd (0, 0, 1); >> >> > TEST_VERIFY_EXIT (r == -1); >> >> > - if (errno == ENOSYS) >> >> > - FAIL_UNSUPPORTED ("kernel does not support pidfd_getfd, >> >> > skipping test"); >> >> > + if (errno == ENOSYS || errno == EPERM) >> >> > + FAIL_UNSUPPORTED ("kernel does not support pidfd_getfd," >> >> > + " or we don't have >> >> > PTRACE_MODE_ATTACH_REALCREDS" >> >> > + " permissions, skipping test"); >> >> > } >> >> >> >> This also hints towards a broken seccomp filter. >> > >> > 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. >> >> But what does it mean for a process to have PTRACE_MODE_REALCREDS? > > #define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS) > > PTRACE_MODE_ATTACH_REALCREDS means > * PTRACE_MODE_REALCREDS which means cred->{g,u}id of the task are used > for permission checking: > > 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. > > 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. > > If both don't apply the request is denied with -EPERM. I think this doesn't apply to the pidfd_getfd (0, 0, 1) 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). 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. Thanks, Florian