Патчим процессы в Linux на лету при помощи GDB

[@devpony]

Очень классно, спасибо. Проверить, правда, не получилось:
Python Exception <class 'gdb.error'> No symbol table is loaded.

[@Vayun]

А GDB грузит символы библиотек? Должен при запуске писать что-то вроде
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6

Я проверил в GDB версий 7.6 и 7.8, одна из них не хотела грузить символы автоматом из командной строки, если писать gdb -p PID. Но gdb -ex "attach PID" работал в обоих.

Можно попробовать запустить просто gdb и ввести команды вручную

> gdb
(gdb) attach PID
(gdb) sharedlibrary .*
(gdb) source /path/pyinject.py
(gdb) set hookfile /path/hook.py
(gdb) pyinject hook open
(gdb) continue

[@devpony]

Когда пытаюсь выполнить attach, получаю
ptrace: Операция не позволена.
GDB версии 7.8

[@Vayun]

Скорее всего ядро с CONFIG_SECURITY_YAMA (ptrace_Protection). Надо разрешить ptrace для юзеров

sudo sysctl -w kernel.yama.ptrace_scope=0

Или запускать gdb от root

[@jonie]

а можно на этом месте подробнее описать систему безопасности. Например есть ли возможность дать такие права (на отладку) только конкретному юзеру, не входящему в какие-то спец группы администрирования?

[@Vayun]

Если защита включена, то для ptrace процесса нужна CAP_SYS_PTRACE capability, которая по-умолчанию есть только у root. Без CAP_SYS_PTRACE можно делать только ptrace child процесса, т.е. gdb ./prog будет работать, а gdb -p PID нет.

Теоретически можно написать launcher с setuid root, который сбросит все права кроме CAP_SYS_PTRACE и запустит нужный процесс. Но мало смысла это делать на уровне пользователя, проще отключить защиту и пользователь сможет делать ptrace любого своего процесса.