Re: Processes running path
Re: Processes running path
- Subject: Re: Processes running path
- From: Terry Lambert <email@hidden>
- Date: Fri, 17 Jun 2005 19:59:10 -0700
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.
-- Terry
On Jun 17, 2005, at 4:35 PM, matt jaffa wrote:
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 <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden