From: ramsdell@mitre.org (John D. Ramsdell)
To: linux-audit@redhat.com
Subject: An autrace that follows forks
Date: 11 Oct 2006 16:06:48 -0400 [thread overview]
Message-ID: <ogtbqoiwraf.fsf@divan.mitre.org> (raw)
I plan to write a version of autrace that follows forks. When run in
follow forks mode, it will ptrace the child. Each time the child or
one of its descendents creates a new process, the program will use the
API provided by libaudit to add an audit rule for the freshly created
process. If I hear of interest in this capability, I'll prepare a
patch against the most recent audit source release, and share.
Last summer, someone else in my company made a simple version of a
fork following tracer based on the audit library; however it does not
compile on my FC5 machine. The reason is he was including the
kernel's headers for ptrace, which defines PTRACE_O_TRACEFORK and
other symbols not part of the standard ptrace header. I don't like
the idea of requiring kernel headers to compile the extended version
autrace.
I studied the strace source code, in particular, strace.c and
process.c. I ran the preprocessor on these files using the options
created on an FC5 machine, and my comments refer to the preprocessed
version of these source files.
When asked to follow forks, in addition to calling ptrace with the
PTRACE_TRACEME option in the child, strace uses procfs to find the
task ID of the process PID in the directory /proc/PID/task.
Apparently, it's the only file name in the directory that parses as a
positive number. Using ptrace to attach to the task ID allows strace
to follow forks. I'm guessing that I have to set a ptrace option so
that the parent is signaled on every descendent system call, and
inspect each system call to see if a new process was created. I bet
following more of the strace logic will allow me to figure out these
details.
I'm worried that blindly following strace's ways may lead me astray.
Is there someplace I can find high-level documentation on when to use
ptrace and when to use the procfs? Should I also study the GDB
sources?
John
next reply other threads:[~2006-10-11 20:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-11 20:06 John D. Ramsdell [this message]
2006-10-11 20:24 ` An autrace that follows forks Steve Grubb
2006-10-12 10:51 ` John D. Ramsdell
2006-10-13 14:07 ` Steve Grubb
2006-10-15 15:32 ` John D. Ramsdell
2006-10-11 20:55 ` James Antill
2006-10-12 11:09 ` John D. Ramsdell
2006-10-12 11:40 ` John D. Ramsdell
2006-10-13 13:50 ` John D. Ramsdell
2006-10-15 15:38 ` John D. Ramsdell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ogtbqoiwraf.fsf@divan.mitre.org \
--to=ramsdell@mitre.org \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox