Re: What's eating gilbert pid? (kevent NOTE_FORK and pids question)
Re: What's eating gilbert pid? (kevent NOTE_FORK and pids question)
- Subject: Re: What's eating gilbert pid? (kevent NOTE_FORK and pids question)
- From: Derrick Brashear <email@hidden>
- Date: Fri, 19 Feb 2010 14:59:24 -0500
On Fri, Feb 19, 2010 at 2:52 PM, Terry Lambert <email@hidden> wrote:
> On Feb 19, 2010, at 9:45 AM, Derrick Brashear wrote:
>>
>> I want to track forked children of a given pid. For the purpose of
>> this discussion, I am userspace code (I could be kernelspace code if
>> it helped)
>
> [ ... ]
>
>> If I can really not have this, Launchd seems to use a sysctl to
>> enumerate children on a fork:
>> int mib[] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL, j->p };
>>
>> (KERN_PROC_PPID seems to not be implemented in xnu-1456.1.26)
>>
>> Am I really reduced to this? It seems very likely to be racy.
>
> It is. It is also SPI (System Private Interface), subject to change on
> every software update (SPI can be thought of as a contract between system
> components which all agree to be updated in lock-step with each other when
> updates happen). Please do not use this sysctl.
Ok.
> A better way is to use ptrace (for some definition of "better"; it's still
> not a good idea to need to know this, and ptrace has its own issues). This
> is what gdb and other debuggers do. If you are denied the rights to do this
> via ptrace, it's probably because you aren't supposed to be doing it. If
> so, then you should expect that the sysctl-based enumeration will probably
> also deny you that right at some point in the future, so even if you can
> hack it so that it works now, it will probably break at some later date.
That's also not really "better". Alas, what I really want to do is
track processes in some way such that marking a process causes that
mark to be inherited by children, and allow the kernel to read the
mark, and a process can cause itself to get a new mark which will be
inherited to *its* future children, and it seems that's simply not
possible:
-The MAC subsystem isn't supported
(http://developer.apple.com/mac/library/qa/qa2007/qa1574.html)
-login contexts and audit sessions are one-per-process and owned by
system software
-I'm insufficiently special to use a mach special port (there are 7)
-The kauth external cred resolver interface allows but a single
resolver and I'm not memberd.
--
Derrick
_______________________________________________
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