Re: Notification of fork()
Re: Notification of fork()
- Subject: Re: Notification of fork()
- From: "Curtis Jones" <email@hidden>
- Date: Tue, 26 Dec 2006 16:34:28 -0500
On 12/26/06, Michael Smith <email@hidden> wrote:
I tried to parse your original description, but was unable to deduce
what you're actually trying to do.
Are you attempting to determine the identity of the originator of the
incoming connection, or the party that will ultimately call accept(2)?
Is there any reason why you have to know early, rather than waiting
until the connection is accepted before determining whether or not to
block it?
This is for purposes of approval. Outgoing connections are a
walk-in-the-park in comparison.
When an incoming connection is, um, coming in, to a listener to which
my socket filter is attached, the connect() callback is called for the
listener socket. Based on the return value from that callback, the new
incoming connection will be allowed/denied.
This decision is based off the endpoint information for the socket and
the associated process information.
I have not tried to close a socket that my kext did not explicitly
open, but assuming that I could, then I could perhaps postpone the
decision by preventing any data send/recv until the pid was known for
the new socket. Without being aware of fork()'s, I wouldn't always
know the path-to-executable, but knowing the correct pid is ...
something.
So, to plainly answer your question: I'd like to know both the remote
endpoint and the party (ie, the pid that called accept(), and the pid
that started the listener (so that I can know the name of the
executable)) that called accept().
The project is this: http://glowworm.us
--
Curtis Jones
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden