From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id A463C385803D for ; Mon, 27 Jun 2022 14:21:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A463C385803D Received: by mail-oi1-x234.google.com with SMTP id be10so13027053oib.7 for ; Mon, 27 Jun 2022 07:21:51 -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=FcgU959qKavzuBvc7QadZmS3W1Fs68d/qWURtx/AI08=; b=Iq7TYrcwbX317o0/MZmRkjrvd6dUg3A73oNAQV58iNZFAkflGIZEZVLdJR4u+90/OB 7bARK65jcwPvukw/T8uEKpEYhqZFKExh9iLgU05119jLKVBcVYGKgrVYphG0mNmHTXYS RIBrnNbT0ufxF0pIPNnGLTfO4t+2+d7VjcieOTkCBcxJzmL2y/frUiHzQFgeT2CLjV0G CWmJv2Uud7w90VhNvhShyWiRg+OVDrWYU7YqprQ66yjkYDdSITOKCELS1ZJ4qsKcz2FR fmV946UGcAHeByVK07zN6NwvlZNoqt4V7zA2GwIGDEoq/TxiPh82nSyqN/5B7ldV5SyM FvzA== X-Gm-Message-State: AJIora8LYIQdU18tBFcyhKy9kZdpwoLchNOHB6ZnPlarIez4ZapHonIo hQ0HRCAs/R1YES8/R7VVV1bVdA== X-Google-Smtp-Source: AGRyM1s1Ne6lVib3dQjuDXVtg+F7+Ykjgfq5OyIXEnFp3HGHmKW9hKtm+aDFGZryJGBH39Seyk2ZUQ== X-Received: by 2002:aca:b289:0:b0:32f:1df7:ba51 with SMTP id b131-20020acab289000000b0032f1df7ba51mr10573668oif.296.1656339710854; Mon, 27 Jun 2022 07:21:50 -0700 (PDT) Received: from smtpclient.apple ([2804:431:c7ca:6d95:e1d4:5b7b:d7d4:ce7e]) by smtp.gmail.com with ESMTPSA id l26-20020a056830055a00b0061697cd25f3sm6232688otb.55.2022.06.27.07.21.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jun 2022 07:21:50 -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: Date: Mon, 27 Jun 2022 11:21:46 -0300 Cc: Christian Brauner , Florian Weimer , libc-alpha@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <076F2F4B-7091-4F18-AD2E-FA9BD006F406@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> To: Mark Wielaard X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, 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:21:53 -0000 > On 27 Jun 2022, at 11:17, Mark Wielaard wrote: >=20 > Hi, >=20 > On Mon, Jun 27, 2022 at 01:51:41PM +0200, Christian Brauner wrote: >> On Mon, Jun 27, 2022 at 01:14:06PM +0200, Florian Weimer via = Libc-alpha wrote: >>> * Mark Wielaard: >>>> 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 >> The second stage of permission checking is: >> (1) If the task isn't dumpable then you'll need CAP_SYS_PTRACE in the >> ptracee's mm user namespace. That userns may differ from the >> ptracee's current userns if the ptracee's userns wasn't privileged >> over the inode of the file it exec'ed and thus could be an = ancestor >> userns (see would_dump()). >> (2) The LSMs might deny your request. >=20 > Right, it is pretty difficult to determine why you got an EPERM. But > failing with EPERM is documented behaviour for pidfd_getfd, so IMHO if > we get EPERM we should simply skip the test whatever the "real" reason > is. I agree, this is possible return code for the syscall so we should handle it on testcase. >=20 > The ptrace manual page lists the whole (6 step) algorithm under > "Ptrace access mode checking": > https://man7.org/linux/man-pages/man2/ptrace.2.html >=20 > It also depends on (not) having CAP_SYS_PTRACE and the permission > might be dependend on /proc/sys/kernel/yama/ptrace_scope >=20 > Cheers, >=20 > Mark >=20