¿Cómo resolver la “operación ptrace no permitida” al intentar adjuntar GDB a un proceso?

5 minutos de lectura

avatar de usuario
bbaytemir

Estoy tratando de adjuntar un programa con gdb pero devuelve:

Adjunto al proceso 29139
No se pudo adjuntar al proceso. Si su uid coincide con el uid del proceso de destino, verifique la configuración de /proc/sys/kernel/yama/ptrace_scope, o vuelva a intentarlo como usuario root. Para obtener más detalles, consulte /etc/sysctl.d/10-ptrace.conf
ptrace: Operación no permitida.

gdb-debugger devuelve “Error al adjuntar al proceso, verifique los privilegios e intente nuevamente”.

strace devuelve “adjuntar: ptrace(PTRACE_ATTACH, …): Operación no permitida”

Cambié “kernel.yama.ptrace_scope” de 1 a 0 y /proc/sys/kernel/yama/ptrace_scope 1 a 0 y probado set environment LD_PRELOAD=./ptrace.so con este:

#include <stdio.h>
int ptrace(int i, int j, int k, int l) {
    printf(" ptrace(%i, %i, %i, %i), returning -1\n", i, j, k, l);
    return 0;
}

Pero sigue devolviendo el mismo error. ¿Cómo puedo adjuntarlo a los depuradores?

avatar de usuario
wisbucky

Si está utilizando Docker, probablemente necesitará estas opciones:

docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined

Si está utilizando Podman, probablemente necesitará su --cap-add opción también:

podman run --cap-add=SYS_PTRACE

  • Incluso si la pregunta no mencionaba a Docker, llegué aquí por eso. Esto me resolvió y gracias por ir más allá de la pregunta.

    – Perennialista

    13 de marzo de 2018 a las 17:31

  • Esto funcionó para mí ejecutando GCC 8.2 y GDB 8.1 en Docker

    – Theta Sinner

    29 de julio de 2018 a las 18:27

  • ¿Cómo puedo hacer esto cuando hago docker build en lugar de ejecutar? no parece tomar esos argumentos? (Tengo un error extraño que solo ocurre cuando se usa Dockerfile)

    – Fersarr

    4 oct 2018 a las 10:31

  • En docker-compose.yml solo tuve que agregar cap_add: - SYS_PTRACE (con una nueva línea después de los dos puntos) en la especificación de mi contenedor.

    – Rafael G.

    4 de febrero de 2020 a las 9:16

  • En la versión más reciente de Docker 18+, --security-opt seccomp=unconfined ya no es necesario.

    – BZ

    24 de septiembre de 2020 a las 15:58

avatar de usuario
Jesús

Esto se debe al endurecimiento del núcleo en Linux; puede deshabilitar este comportamiento por echo 0 > /proc/sys/kernel/yama/ptrace_scope o modificándolo en /etc/sysctl.d/10-ptrace.conf

Ver también este artículo sobre ello en Fedora 22 (con enlaces a la documentación) y este hilo de comentarios sobre Ubuntu y .

  • los echo ... solo funcionó en mi caso si abrí una consola raíz primero con sudo -i (sudo echo ... no funcionó debido al símbolo de redirección)

    – R Yoda

    24 de junio de 2018 a las 12:54


  • Algunas construcciones de shell son difíciles de usar en argumentos para comandos como sudo.

    – jesup

    13 de julio de 2018 a las 11:01

  • Al usar sudo y redirección, puede usar echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

    –Daniel Serodio

    19/09/2018 a las 19:28

  • Los comentarios en este sitio son mejores que la mayoría de las respuestas.

    – doug65536

    17 de julio de 2021 a las 23:17

  • O con sudo bash -c "echo 0 > /proc/sys/kernel/yama/ptrace_scope"

    – Thiago Navarro

    30 de agosto de 2021 a las 23:41

avatar de usuario
Juraj Oršulić

Me gustaría agregar que necesitaba --security-opt apparmor=unconfined junto con las opciones que mencionó @wisbucky. Esto fue en Ubuntu 18.04 (tanto cliente Docker como host). Por lo tanto, la invocación completa para habilitar la depuración de gdb dentro de un contenedor es:

docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined --security-opt apparmor=unconfined

  • Esto no proporciona una respuesta a la pregunta. Una vez que tenga suficiente reputación, podrá comentar cualquier publicación; en lugar de, proporcionar respuestas que no requieran aclaración por parte del autor de la pregunta. – De la revisión

    – Rafael

    7 de octubre de 2018 a las 5:34

  • @Rafael, la respuesta se actualizó con la línea de comando completa. Proporciona una respuesta completamente autónoma a la pregunta ahora.

    – Juraj Oršulić

    17 oct 2018 a las 10:26


Realmente no abordé el caso de uso anterior, pero tuve este problema:

Problema: Sucedió que comencé mi programa con sudoasí que al iniciar gdb me estaba dando ptrace: Operation not permitted.

Solución: sudo gdb ...

avatar de usuario
Nagev

Solo quiero enfatizar un tema relacionado responder. Digamos que eres root y has hecho:

strace -p 700

y obten:

strace: attach: ptrace(PTRACE_SEIZE, 700): Operation not permitted

Controlar:

grep TracerPid /proc/700/status

Si ves algo como TracerPid: 12es decir no 0ese es el PID del programa que ya está usando el rastrear llamada del sistema. Ambas cosas gdb y strace usarlo, y solo puede haber uno activo a la vez.

Como la mayoría de nosotros aterrizamos aquí por problemas de Docker, agregaré el Kubernetes respuesta ya que podría ser útil para alguien …


Debes agregar el SYS_PTRACE capacidad en el contexto de seguridad de su pod en spec.containers.securityContext:

       securityContext:
          capabilities:
            add: [ "SYS_PTRACE" ]

Hay 2 securityContext llaves en 2 lugares diferentes. Si le dice que la clave no se reconoce, entonces la extravió. Prueba con el otro.

Probablemente también necesite tener un usuario root por defecto. Así que en el otro contexto de seguridad (spec.securityContext) agregar :

      securityContext:
        runAsUser: 0
        runAsGroup: 0
        fsGroup: 101

FYI: 0 es raíz. Pero el valor de fsGroup es desconocido para mí. Por lo que estoy haciendo no me importa, pero a ti sí.

Ahora puedes hacer:

strace -s 100000 -e write=1  -e trace=write -p 16

¡Ya no te negarán el permiso!

CUIDADO: Esta es la caja de Pandora. Tener esto en producción NO es recomendable.

avatar de usuario
Suf AB

Estaba ejecutando mi código con mayores privilegios para lidiar con Ethernet Raw Sockets al establecer el comando de capacidad en Debian Distribution. Probé la solución anterior: echo 0 > /proc/sys/kernel/yama/ptrace_scope
o modificándolo en /etc/sysctl.d/10-ptrace.conf pero eso no funcionó para mí.

Además, también probé con el comando establecer capacidades para gdb en el directorio instalado (usr/bin/gdb) y funciona: /sbin/setcap CAP_SYS_PTRACE=+eip /usr/bin/gdb. Asegúrese de ejecutar este comando con privilegios de root.

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad