| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 31 Aug 2006 23:05:47 +0200
From: Andreas Hobein <ah2@...air.de>
To: linux-kernel@...r.kernel.org
Subject: Trouble with ptrace self-attach rule since kernel > 2.6.14
Hi !
I have some trouble with the restriction of the ptrace functionality assumably
introduced into the linux kernel with the patch from 9. 11.2006
1105_2_ptrace-self-attach.patch.
My multithreaded application tries to write callstacks of all threads (some
sort of built-in mini debugger) in case of abnormal situations or failure.
With the newer linux kernel (> 2.6.14) self-attaching to processes of the
same thread group does not work any longer. Any call to ptrace results in a
EPERM result.
I have worked around this problem by first forking the process, than creating
the callstack output in the forked child process - which works without the
above mentioned problem - and terminating the child process just after this
operation.
Anyway this solution is somehow dirty and I would prefer the way it was
implemented before. My question is: Why may a sibling thread not
ptrace_attach another process of the same thread group, while at the same
time a forked child process of the same thread is allowed to do this
operation? Is there any replacement like pthread_suspend, which is available
on other Unixes?
(A short program for the demonstration of this effect is attached. Use Option
-f to enable forking)
Best regards,
Andreas
View attachment "trace.c" of type "text/x-csrc" (1812 bytes)
Powered by blists - more mailing lists