site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -- Terry Well basically I am trying to associate outgoing traffic with the process that is sending it using a socket filter. It works great, and right now I have my kext sending the pid to a super user process in user space that gets the process path and sends it back. This is less than ideal, I would rather have the kext be able to get this info. In Panther I wrote my own function in the kernel that would look at the process structure and look at the path from the process user space stack. But now Tiger hides the process structure definition and other definitions my function used so it has become useless in Tiger. I just don't want my application to have all these processes have to be running for it to work. Matt On 6/17/05, Terry Lambert <tlambert@apple.com> wrote: On Jun 16, 2005, at 11:18 PM, Josh Graessley wrote: There isn't a good, straightforward way of doing this. If you get in touch with DTS, they may be able to work with you towards a solution. We are aware of the issue and have a bug (enhancement request) filed to track it. -josh On Jun 16, 2005, at 9:31 PM, matt jaffa wrote: Does anyone on this list know of some api or hack of using a processes id (pid) in a network kernel extension to get that process running path? Thanks Matt Specifically, the path is stored into the strings area at the top of the user stack during the exec process for use by the "open(1)" command in obtaining bundle ID information. Because this is in memory belonging to the user process, it's possible for the user process to modify its contents after the application has started, so you cannot trust that the information is reliable or accurate to create a security association (as one example use someone might have for needing this information). If it's not for a security association, one method would be to have to program tell the kext. For bundle information, the most correct thing for the process to do is to write a file in /var/run with the information; this is probably not usesful for a kext, though, since you shouldn't be trying to do file I/O from a kext. If you can tell us why you need the information, we can probably tell you a different way to solve the problem you are trying to solve. -- Terry _______________________________________________ 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... You could probably do the same thing you were doing, if you link against the specific kernel, instead of linking against the KPI restricted symbol sets. If you did that, though, you would end up having to recompile your kext each time Aplle releases a software update that changes a minor version number - that's intentional, since the KPI's are intended to document what we think won't change between versions, and so it's safe to use and won't change between software updates. The user space daemon seems to me to be the correct approach, actually, since it's (A) more portable and (B) less likely to stop working following an OS update and (C) is likely more portable to Intel systems and (D) will work when it's run under Rosetta. The type of lookup you are trying to do is expensive enough that it should be decoupled from the functioning of the driver. If you just need the command name, and don't care about it's full path, you can get that easily enough from the visible information in the kernel. Most users of the full path tend to be programs in user space that use it to obtain bundle IDs (better done by popen'ing "ps" with the appropriate parameters to get just the process and data you are interested in, and reading only it). That's assuming they don't simply write out a "/var/run/bundle.XXX" file for the other programs that want to rendezvous with the program running from the bundle, which is an even better approach. On Jun 17, 2005, at 4:35 PM, matt jaffa wrote: This email sent to site_archiver@lists.apple.com