Re: [PATCH v2] Improve ptrace-error detection on Linux targets

[Sergio Durigan Junior <sergiodj@redhat.com>]

On Wednesday, September 04 2019, Pedro Alves wrote:

> On 9/4/19 8:31 PM, Sergio Durigan Junior wrote:
>> I forgot to say, but the way my patch works now prevents the code path
>> above to be executed.  My patch catches the ptrace failure very early in
>> gdbserver initialization the process, when linux_child_function is
>> called during the execution of linux_check_ptrace_features.  Since
>> linux_child_function will try to perform a PTRACE_TRACEME (and fail if
>> there are any restrictions in place), gdbserver will error out before it
>> even tries to spawn/attach.
>> 
>> Nevertheless, during my tests I bypassed linux_check_ptrace_features and
>> confirmed that the error message from linux_attach (above) is correctly
>> displayed:
>> 
>>   [sergio@fedora-rawhide build]$ sleep 120 &
>>   [5] 2732388
>>   [sergio@fedora-rawhide build]$ ./gdb/gdbserver/gdbserver :9911 --attach 2732388
>>   gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Operation not permitted
>>   gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED!
>>   gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2732391 No such process
>>   Cannot attach to process 2732388: 
>> 
>>   The SELinux 'deny_ptrace' option is enabled and preventing GDB
>>   from using 'ptrace'.  You can disable it by executing (as root):
>> 
>>     setsebool deny_ptrace off
>> 
>>   The Linux kernel's Yama ptrace scope is in effect, which can prevent
>>   GDB from using 'ptrace'.  You can disable it by executing (as root):
>> 
>>     echo 0 > /proc/sys/kernel/yama/ptrace_scope
>> 
>>   Exiting
>
> So if you _don't_ hack linux_check_ptrace_features, what does the user
> see, with either
>
>         gdbserver [OPTIONS] --attach COMM PID

Basically the same thing:

  [sergio@fedora-rawhide build]$ ./gdb/gdbserver/gdbserver :9911 --attach 2733600
  gdbserver: linux_ptrace_test_ret_to_nx: Cannot PTRACE_TRACEME: Operation not permitted
  gdbserver: linux_ptrace_test_ret_to_nx: status 256 is not WIFSTOPPED!
  gdbserver: linux_ptrace_test_ret_to_nx: failed to kill child pid 2733602 No such process
  gdbserver: Could not trace the inferior process.
  gdbserver: ptrace: Operation not permitted
  The SELinux 'deny_ptrace' option is enabled and preventing GDB
  from using 'ptrace'.  You can disable it by executing (as root):

    setsebool deny_ptrace off

  The Linux kernel's Yama ptrace scope is in effect, which can prevent
  GDB from using 'ptrace'.  You can disable it by executing (as root):

    echo 0 > /proc/sys/kernel/yama/ptrace_scope

  linux_check_ptrace_features: waitpid: unexpected status 32512.
  Exiting

The only difference is that we don't see the "Cannot attach to process
PID:" message.

> or extended-remote + "(gdb) attach" ?

I'm trying to come up with a way to test this.  The only way would be to
make gdbserver successfully start so that we could perform an
extended-remote connection from GDB.  However, if gdbserver starts
without problems, this means that the ptrace check succeeded and that
there are no ptrace restrictions in place.  Therefore, an "attach" would
succeed as well.  Which means that even if we're running GDB in a
ptrace-restricted system, things will go OK as long as gdbserver is not
restricted.  In this case, we wouldn't see any error messages IIUC.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/