site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Is this right? S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ 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). This email sent to site_archiver@lists.apple.com