Re: Determine a process that "owns" the socket_t
Re: Determine a process that "owns" the socket_t
- Subject: Re: Determine a process that "owns" the socket_t
- From: James J <email@hidden>
- Date: Mon, 23 May 2011 02:22:19 +0300
Hello Ken,
Thank you for the elaborate answer and patience for my not being able to find the answer by myself :-)
For some sockets i may find a process ID. Great!
Basically what i wanted - is to see if "my" special process created that socket, or any other application. If it was not "my" process - i will perform some additional filtering.
Thus, i want to identify if the socket_t, to which my NKE had been attached, was created by "my" or not "my" process.
I realize that identifying application by a process name is an unreliable thing. That is why i am looking for some detours.
The closest thing i came up with - is to somehow "ask" the process if it is "mine", right in "filter_attached_to_socket" NKE's callback.
I am searching for the way to 'ask' it, it should be some kind of IPC, but i am not sure which one. The only thing i was using for kernel-userland communication were Control Sockets, but the conversation for these is initiated by an application not the kernel extension (while i need a driver to ask the application, not vice versa, - of course with all error checking and "app not responding/not loaded" correct processing). I am not even sure if that is possible to do at all.
Could you please give me some idea, where to go from?
Thank you,
James
2011/5/5 Ken Hornstein
<email@hidden>
>I am writing an NKE filter, and I'm wondering if i could get a process
>name (ideally - a full path to the process) that my filter has been
>attached to. When my "attach" function has been called, i have a
>pointer to the socket_t structure. Is there any way to trace the way
>to the process (a process' PID identifier) that has opened this
>socket, and find out its name?
You know, this question has been asked (and answered) in the mailing
list archives :-) But, in short:
- You can't necessarily turn a socket_t into a process (because multiple
processes could have that descriptor).
- But you can find out the context that invoked you at NKE attach time,
which at least in some cases will be the userspace process. See the
Apple sample code for tcplognke, specifically the use of proc_selfpid().
Note that in some cases (see the mailing list archives) this won't be
useful to you.
- You can use proc_selfname() to get at p_comm, which is probably the
closest thing to what you want. But you should read this first:
http://lists.apple.com/archives/darwin-kernel/2008/Mar/msg00086.html
Although ... I'm sure Michael Smith has forgotten more about the Darwin
kernel than I will ever know, but I don't see how you can change p_comm
from userspace. But all of the usual caveats apply here - using this
is almost certainly the Wrong Thing to do.
--Ken
_______________________________________________
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