linux-kernel - ptrace() behaviour when doing PTRACE

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Sun, 28 Aug 2011 15:43:07 -0300
From:	Pablo Antonio <pabloa@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: ptrace() behaviour when doing PTRACE_KILL

Hello,
    I was writing some user code that uses the ptrace() system call
and found it wasn't behaving as I expected. Maybe this is simply
because I don't know enough about ptrace()'s behaviour, so I'd like
someone to enlighten me with some information.

So, here's the code: http://codepad.org/TJ7Lua4Q Basically, I was
expecting the parent process to kill the child when the later
attempted to use the kill() system call, not letting it send signals
to other processes. I had done this before with pretty much the same
code, but instead of killing when kill() was called, I was doing it
when a fork() or clone() was attempted. And it worked. If the child
process tried to create a new process via fork() or clone(), then it
was immediately killed and no process was created.

But now that I'm doing the same thing with kill(), I'm seeing that the
child process ends up killed, as expected, but the signal is sent
nonetheless. I understand that when I do the PTRACE_KILL, a SIGKILL
signal is sent to the child. And PTRACE_KILL is used on syscall
entrance in that code. If the SIGKILL signal is delivered to the
process before it continues executing the system call in kernelspace,
then I don't understand why this code doesn't work as expected. If the
signal is delivered after the system call is completely executed, then
I don't understand why this was working for the fork() and clone()
case.

I'd really appreciate if someone told me what's happening here, or
what I'm not seeing.

Thanks,

-- 
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/