site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jan 2, 2007, at 2:11 AM, Quinn wrote: = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... At 4:38 -0500 2/1/07, Curtis Jones wrote: Any chance you have any suggestions on how else to approach this? The biggest problem is the context in which you're running, which rules out many possibilities (like round tripping to user space). To address your question properly, I need a better understanding of exactly what you're doing. Here's what I think you're doing: A. By listening on KAUTH_FILEOP_EXEC, you maintain a table that maps PIDs to paths. B. By listening on sf_attach_func, you maintain a table that maps sockets to PIDs. C. In sf_connect_in_func, you use this information to determine whether to allow the connection. You problem is that, if a process forks but doesn't exec, and the child process creates a listening socket, you don't have any information about the child process to attach to the socket (at point B above). And in this case, is there any reason that (since you have previously said that approximations are OK) you can't simply walk the process parent chain looking for a PID that you recognise? This email sent to site_archiver@lists.apple.com