Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp42440pxu; Tue, 15 Dec 2020 15:21:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJwCzSiAsv7CHSOxz25pqQrKJeQJeKbE3PinDghM9IKBWyl1eFYSU1YannUVAECmwxUoxrt2 X-Received: by 2002:a17:906:1e0c:: with SMTP id g12mr29184853ejj.115.1608074500154; Tue, 15 Dec 2020 15:21:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608074500; cv=none; d=google.com; s=arc-20160816; b=R01yGHThS7ffzroDgr/Y0nGn4uyUhy2GaX3e7XHvXTmfHZv5SyvK20ENpY8jLrFRL5 Kat+8pZaI3mYw3ZPsPLl+ZlkieqCe55ODSDbAuQYQfBju60YUgbeFavO+Zfq5Fj2WqRC k+JjumxAjTvzoVUXfKDKsUu18V7D+1BCRTn+amulXA6CfbUcIW3DzXLrcE7PplQ2eFba 8+ALUra8eHQ3VlPBIxayiA03WkHbKAS7v/LrvB1gcoCZolXbZKPKIyRAdwy/j86OOPa/ /YwC4hBvnBcGqhPkhx7OyPZULA4teRfBmkVSvzSqaVAUswod+GUy/R/1NFrR/muHH9QZ AHMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject:dkim-signature; bh=RWTdo7l7B/SOH7EWwFmGvBqYnRSrVGaVN94yY6EDipE=; b=hkEhbGR27eT/MkL7ViHk5cw+d61/0wFIBeNEkJW5ETxO4gji77Bwe51ZGdFZDG+0KF kmgAhLZsOC8mq9vLReh4pzljYHW0E48G5SFnYJfjEMvnJJ/eZpO51DUCuOfpE+7byyJm 7ToxjRSch1/08EyK2jVZ7lSV3ZCFSbjZ0QGTbIlmizHDeGn0JyDoiZNmSE0XKaqUixNp W6NtBBmFnxqOJhm0/F6K9MBn5oynA32cBUUcr3mXoJMhw4C0wwPj+2xL14imcGlTWE0i SvZUwGwhNPu9EH6s6+sLBdGwLQLi1UkTebk/q2ho1akRILGCwLwZpalFMLfIe3o/gBPM tYWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=M2hjolxQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ci19si1998ejb.718.2020.12.15.15.21.13; Tue, 15 Dec 2020 15:21:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=M2hjolxQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729716AbgLOWs7 (ORCPT + 99 others); Tue, 15 Dec 2020 17:48:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727068AbgLOWs4 (ORCPT ); Tue, 15 Dec 2020 17:48:56 -0500 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1D05C0613D3; Tue, 15 Dec 2020 14:48:15 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id g25so789661wmh.1; Tue, 15 Dec 2020 14:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RWTdo7l7B/SOH7EWwFmGvBqYnRSrVGaVN94yY6EDipE=; b=M2hjolxQdQNzwTd38OCRE2DXoCSXTFZ+aZBAesh1bVtg62r7MQw9KErIw8fm0+8aN5 dcvtsLlB7xoSImuq2yPH6uHKK9Kd1yjAU+/90JAdmjybC2g2rccIZeag4+041RZN2cCG uFO72ex3HO5T6HN8auWXlQ/ZK+LvZ8GzaxQWApSFEIDfy7XFSt7yLaotuOZ38tro4T1J 7ksNvdgd/WEZM1FyC9sSY7Q0TvvnLg6WqDyjXmymifD+L4sWSK/Y0ftVics4ZFwA/jQ6 ajshzUnmTy4mqzs+3s/FZnwN8dmdKaUchqe1waNlTKe0gCmPs7PzhRboJRHIptDT5Dy4 6bNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RWTdo7l7B/SOH7EWwFmGvBqYnRSrVGaVN94yY6EDipE=; b=JHxTPG5U4J3Kt8TK/JnsC0lXVgfQwgyNUuUGKBCl89/qXmH4cXHdT4h8Qkmau91xOW SY+ijZ66yH7iORaQ/TzPfj6hgEn/PL8c5PUdVY9W+1z0eL01ZAxSnLj8WrLZHgpuZlMJ qFtOuPkeJTzl5lYxA0sI+NWZ+4PWqS2XIXE4eB7nk6paKqw8/iO13PQjruRVqbSoay5X 8l051FRmf6sqlBRh1G09H8fEokkxQ3XIcJHSzy/oGY6ooY7O1xL5B9KHjKd5ZrkCbs1f Tpa87JspRFyU36O1jzBZOI3j21wOc0ayY/DhOkgxJtZan7SAoyS6HrtkAh/u8wT132Ja 8bWw== X-Gm-Message-State: AOAM530PRYS4SOLve3eaR5hFjIMYnpUFv60p5Poxbt3U+xS0BTmCH2mm z8KX/4QEAevckOo9gCAtCPU= X-Received: by 2002:a1c:6283:: with SMTP id w125mr665100wmb.155.1608072494168; Tue, 15 Dec 2020 14:48:14 -0800 (PST) Received: from [192.168.0.160] ([170.253.49.0]) by smtp.gmail.com with ESMTPSA id t13sm5739wrs.26.2020.12.15.14.48.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Dec 2020 14:48:13 -0800 (PST) Subject: Re: [Bug 210655] ptrace.2: documentation is incorrect about access checking threads in same thread group From: "Alejandro Colomar (man-pages)" To: Ted Estes , Pavel Emelyanov , Oleg Nesterov , Andrew Morton , Michael Kerrisk , Kees Cook , Jann Horn Cc: linux-man , linux-kernel , Linus Torvalds , Oleg Nesterov , Markus Gutschke , Roland McGrath , Andreas Hobein References: <223477a0-0b92-3a01-46bb-c06f7d5d5901@gmail.com> Message-ID: <0df0ac9e-e881-88c7-cea9-5154077c95a9@gmail.com> Date: Tue, 15 Dec 2020 23:48:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <223477a0-0b92-3a01-46bb-c06f7d5d5901@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [CC += Andreas, Linus, Roland, Markus; fixed Oleg] On 12/15/20 7:34 PM, Alejandro Colomar (man-pages) wrote: > Hi Ted, > > On 12/15/20 7:31 PM, Ted Estes wrote: >> Per my research on the topic, the error is in the manual page. The >> behavior of ptrace(2) was intentionally changed to prohibit attaching to >> a thread in the same group. Apparently, there were a number of >> ill-behaved edge cases. >> >> I found this email thread on the subject: >> https://lkml.org/lkml/2006/8/31/241 Okay, after reading the LKML thread, the old behavior was removed because it was very buggy. We have two options now: 1) Remove that paragraph, as if that behavior had never existed. If we do this, not much is lost: Only _very_ old kernels had that behavior, and it's not even advisable to make use of it on those, AFAICS. 2) Add a note to that paragraph, saying that since kernel 2.X.Y? the calling thread and the target thread can't be in the same group. Cons: That info is unlikely to be useful, and will only add a few more lines to a page that is already very long. 3) Suggestions? I prefer option 1. I'll add a larger screenshot of the manual page below, so that readers don't need to read 'man 2 ptrace': [[ ... The algorithm employed for ptrace access mode checking deter‐ mines whether the calling process is allowed to perform the corresponding action on the target process. (In the case of opening /proc/[pid] files, the "calling process" is the one opening the file, and the process with the corresponding PID is the "target process".) The algorithm is as follows: 1. If the calling thread and the target thread are in the same thread group, access is always allowed. 2. If the access mode specifies PTRACE_MODE_FSCREDS, then, for the check in the next step, employ the caller's filesystem UID and GID. (As noted in credentials(7), the filesystem UID and GID almost always have the same values as the corre‐ sponding effective IDs.) Otherwise, the access mode specifies PTRACE_MODE_REALCREDS, so use the caller's real UID and GID for the checks in the next step. (Most APIs that check the caller's UID and GID use the effective IDs. For historical reasons, the PTRACE_MODE_REALCREDS check uses the real IDs instead.) ... ]] Any thoughts before I write the patch? Thanks, Alex > > Thank you for all the details and links! > I'll fix the page. > > Thanks, > > Alex > >> >> Thank you. >> --Ted Estes >> >> On 12/15/2020 11:01 AM, Alejandro Colomar (man-pages) wrote: >>> Hi, >>> >>> There's a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=210655 >>> >>> [[ >>> Under "Ptrace access mode checking", the documentation states: >>> "1. If the calling thread and the target thread are in the same thread >>> group, access is always allowed." >>> >>> This is incorrect. A thread may never attach to another in the same >>> group. >>> >>> Reference, ptrace_attach() >>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/kernel/ptrace.c?h=v5.9.14#n380 >>> >>> ]] >>> >>> I just wanted to make sure that it is a bug in the manual page, and not >>> in the implementation. >>> >>> >>> Thanks, >>> >>> Alex >>> >> >