[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0df0ac9e-e881-88c7-cea9-5154077c95a9@gmail.com>
Date: Tue, 15 Dec 2020 23:48:12 +0100
From: "Alejandro Colomar (man-pages)" <alx.manpages@...il.com>
To: Ted Estes <ted@...twarecrafters.com>,
Pavel Emelyanov <xemul@...nvz.org>,
Oleg Nesterov <oleg@...sign.ru>,
Andrew Morton <akpm@...ux-foundation.org>,
Michael Kerrisk <mtk.manpages@...il.com>,
Kees Cook <keescook@...omium.org>, Jann Horn <jann@...jh.net>
Cc: linux-man <linux-man@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
Markus Gutschke <markus@...gle.com>,
Roland McGrath <roland@...hat.com>,
Andreas Hobein <ah2@...air.de>
Subject: Re: [Bug 210655] ptrace.2: documentation is incorrect about access
checking threads in same thread group
[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
>>>
>>
>
Powered by blists - more mailing lists