permissão negada para ptrace no GDB

Question

Inicialmente eu publiquei esta pergunta no StackOverflow , como um problema do GDB. Eu não encontrei uma solução lá, mas eles me ajudaram a descobrir que é um problema de permissões, então estou postando aqui.

Eu configurei um programa C super simples e o compilei com o GCC (com o -g flag). Eu tentei executá-lo com gdb a.out , definir um ponto de interrupção em main e executá-lo, mas o GDB ignorou meu ponto de interrupção e simplesmente executou o programa inteiro sem parar.

Em minhas perguntas no SO, eles me disseram para executá-lo com strace e grep para chamadas com falha no ptrace. Eu fiz isso e consegui:

5765 ptrace(PTRACE_TRACEME, 0, 0, 0) = -1 EPERM (Operation not permitted)

Quando estou tentando executar gdb com sudo , tudo funciona bem, então definitivamente é um problema de permissões. Eu também tentei reinstalar o GDB, esperando que ele redefinisse as permissões, mas isso não ajudou. Aqui estão os grupos e permissões para o GDB e para o executável que estou tentando depurar:

-rwxr-xr-x 1 idanarye users 7797 Dec 28 04:52 ./a.out
-rwxr-xr-x 1 root root 5206304 Aug 31 07:10 /usr/bin/gdb

Eu tentei googling para este problema, mas tudo que eu poderia encontrar é outro problema onde o GDB não consegue anexar a processos em execução devido a uma nova regra de segurança que impede a inserção de outro processo, a menos que seja um processo filho. Este não é o problema aqui, já que deixei o GDB iniciar o processo que eu quero depurar. Já experimentei a solução sugerida (alterando /proc/sys/kernel/yama/ptrace_scope ) e não funcionou.

O que estou perdendo aqui? Quais permissões eu preciso dar e para quê?

Estou executando um ArchLinux de 64 bits.

UPDATE

Não faço ideia de como ou porquê, mas funciona agora. Provavelmente uma atualização do sistema corrigiu isso ...

    

Answer 1

Eu não acho que a permissão negada esteja necessariamente falando sobre os bits de permissões tradicionais (rwx ..), em vez disso, eu suspeitaria de algo como o SELinux ou o AppArmor, o que pode estar negando o acesso ao processo.

Eu não tenho acesso a um sistema ArchLinux, mas há algo similar no Fedora que é discutido aqui neste tópico do Fedora Wiki: Recursos / SELinuxDenyPtrace .

Aqui eles estão bloqueando o acesso ao ptrace através do SELinux, então você pode querer tentar desabilitar o SELinux ou o AppArmor que o ArchLinux está usando.

Qual foi a sua tentativa para mim

Eu testei o seu código no meu sistema Fedora 19 e, além de precisar instalar alguns RPMs debuginfo adicionais, funcionou como você esperava.

Exemplo

Compile seu código.

$ gcc -g test.c 

Ran o binário resultante em gdb .

$ gdb a.out 
GNU gdb (GDB) Fedora 7.6.1-46.fc19
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/saml/tst/106912/a.out...done.
(gdb) break main
Breakpoint 1 at 0x40053f: file test.c, line 4.
(gdb) run
Starting program: /home/saml/tst/106912/a.out 

Breakpoint 1, main (argc=1, argv=0x7fffffffd698) at test.c:4
4       printf("1\n");
Missing separate debuginfos, use: debuginfo-install glibc-2.17-20.fc19.x86_64
(gdb) quit
A debugging session is active.

    Inferior 1 [process 13341] will be killed.

Quit anyway? (y or n) y

O depurador reclamou que eu estava perdendo o debuginfos para o glibc, então eu os instalei.

$ sudo debuginfo-install glibc-2.17-20.fc19.x86_64

Agora, quando eu executar novamente o gdb

$ gdb a.out 
GNU gdb (GDB) Fedora 7.6.1-46.fc19
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/saml/tst/106912/a.out...done.
(gdb) break main
Breakpoint 1 at 0x40053f: file test.c, line 4.
(gdb) run
Starting program: /home/saml/tst/106912/a.out 

Breakpoint 1, main (argc=1, argv=0x7fffffffd698) at test.c:4
4       printf("1\n");
(gdb)