Re: kqueue EVFILT_PROC and child process pid
Re: kqueue EVFILT_PROC and child process pid
- Subject: Re: kqueue EVFILT_PROC and child process pid
- From: Stacey Son <email@hidden>
- Date: Mon, 12 Oct 2009 10:06:32 -0500
On Oct 12, 2009, at 2:20 AM, Jean-Daniel Dupas wrote:
Le 12 oct. 2009 à 01:01, Stacey Son a écrit :
On Oct 11, 2009, at 3:01 PM, Dave Keck wrote:
As far as getting the the new child's PID, I don't think it's
possible
using the kevent APIs from userland. (sys/event.h mentions "lower
bits
contain the PID of the child", but I think this is kernel-only.)
FWIW:
This depends on which version of Mac OS you are using... Before
10.5 I believe you could use NOTE_TRACK and NOTE_CHILD to get the
PID of the child. The PID of the child would be stored in the
ident field and the PID of the parent (aka. PPID) would be stored
in the data field. I guess this is no longer the case. See sys/
event.h:
/*
* DEPRECATED!!!!!!!!!
* NOTE_TRACK, NOTE_TRACKERR, and NOTE_CHILD are no longer supported
as of 10.5
*/
Best Regards,
The last time I tried to used them is a simple application, it was
triggering a Kernel Panic, until Apple fix that by returning ENOTSUP
when trying to register an event with theses flags.
I never saw a version of OS X that support it.
This explains why these flags were deprecated. :)
Another way to monitor and get the PID of new processes is to use
auditing. See the FreeBSD documentation for the details: http://www.freebsd.org/doc/en/books/handbook/audit.html
In short, you could audit the fork() and posix_spawn() system call
events. The child PIDs are given as arguments to these events. To do
this you will need to add the "process" audit class ("pc") to the
"flags" and "naflags" fields of /etc/security/audit_control (or better
yet, create your own audit class with just these events*) and restart
auditing by doing "sudo audit -s" (or rebooting). You can then read
the events from either the audit trail files in /var/audit or by
reading /dev/auditpipe (see "man auditpipe"). This assumes you are
running 10.6.
Of course, auditing system call events can add some overhead. To
reduce this overhead as much as possible you may want to create a new
audit class with just the system events you would like to audit.
This is done by edit the /etc/security/audit_class and /etc/security/
audit_event files (see 'man audit_class' and 'man audit_event').
Best Regards,
-stacey.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden