Re: [Bug 210655] ptrace.2: documentation is incorrect about access checking threads in same thread group

["Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>]

[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
>>>
>>
>