Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"a PTRACE_MODE_ATTACH_REALCREDS check" and "same UID" are roughly synonyms. ("Roughly" because the actual check also permits privileged processes and denies some special cases such as processes that have done a setuid. REALCREDS, if I remember right, is in contrast to the check done on certain files in /proc.)

It's the same check as ptrace itself, so the intuition is "can I strace or gdb this process."



The big exception to this is inside containers where it is often disabled by default.


AIUI Docker containers by default deny the ptrace syscall (and presumably process_vm_readv/writev), they don't change the permission check. So /proc/$pid/mem, which uses the same permission check, ought to work.

(This also means that you don't want or need CAP_SYS_PTRACE to get gdb/strace working in Docker, that lets you ptrace anything and also coincidentally turns off the syscall filter. Just turn the filter off, that works without privileging the processes in the container.)


Or if you have an LSM such as Yama or SELinux set to deny ptrace globally.


Yama lets you ptrace a child process but not others.


By default, yes.

You can also disable ptrace() completely.

(Grep for "ptrace_scope" in the ptrace(2) man page for details.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: