Is there a way to identify the usermode application that was the IRP
initiator.
for instance identify application that request read/write from disks?
Omri
you can get a pointer to the thread that issued the request out of the
IRP, but there’s nothing in the request which points to the process.
There is information about the thread & process in the thread data
structure but that should be considered opaque so you may not want to
access it. There doesn’t appear to be a DDK exported method for getting
the CLIENT_ID structure from a thread pointer.
knowing which application send an IO can be helpful for logging purposes
if that’s your goal, but please don’t try using it to “secure” your
driver. For example, allowing any process named “myapp.exe” to read
restricted portions of the disk is really never going to be secure since
anyone can launch a binary named “myapp.exe”.
-p
-----Original Message-----
From: Omri [mailto:xxxxx@verizon.net]
Sent: Monday, September 23, 2002 11:12 AM
To: NT Developers Interest List
Subject: [ntdev] Origin of IRP?
Is there a way to identify the usermode application that was the IRP
initiator. for instance identify application that request read/write
from disks?
Omri
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
IoGetRequestorProcess(PIRP Irp) will do just fine, in most of the cases.
However, sometimes a user mode request can be posted to a worker by a filter
driver, using a fresh IRP , and the original requestor can be lost.
Dan
----- Original Message -----
From: “Peter Wieland”
To: “NT Developers Interest List”
Sent: Monday, September 23, 2002 9:21 PM
Subject: [ntdev] RE: Origin of IRP?
you can get a pointer to the thread that issued the request out of the
IRP, but there’s nothing in the request which points to the process.
There is information about the thread & process in the thread data
structure but that should be considered opaque so you may not want to
access it. There doesn’t appear to be a DDK exported method for getting
the CLIENT_ID structure from a thread pointer.
knowing which application send an IO can be helpful for logging purposes
if that’s your goal, but please don’t try using it to “secure” your
driver. For example, allowing any process named “myapp.exe” to read
restricted portions of the disk is really never going to be secure since
anyone can launch a binary named “myapp.exe”.
-p
-----Original Message-----
From: Omri [mailto:xxxxx@verizon.net]
Sent: Monday, September 23, 2002 11:12 AM
To: NT Developers Interest List
Subject: [ntdev] Origin of IRP?
Is there a way to identify the usermode application that was the IRP
initiator. for instance identify application that request read/write
from disks?
Omri
—
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%
IoGetRequestorProcess()
----- Original Message -----
From: “Omri”
To: “NT Developers Interest List”
Sent: Monday, September 23, 2002 10:12 PM
Subject: [ntdev] Origin of IRP?
> Is there a way to identify the usermode application that was the IRP
> initiator.
> for instance identify application that request read/write from
disks?
>
> Omri
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>
If the driver is written correctly the original process obtained via
IoGetRequestorProcess should be valid. This is because the IO manager will
cancel the IRP before the process goes away and this cancel ideally should
propagate through the stacks.
–
Nar Ganapathy
Windows Core OS group
This posting is provided “AS IS” with no warranties, and confers no rights.
“Dan Partelly” wrote in message news:xxxxx@ntdev…
>
> IoGetRequestorProcess(PIRP Irp) will do just fine, in most of the cases.
> However, sometimes a user mode request can be posted to a worker by a
filter
> driver, using a fresh IRP , and the original requestor can be lost.
>
> Dan
>
> ----- Original Message -----
> From: “Peter Wieland”
> To: “NT Developers Interest List”
> Sent: Monday, September 23, 2002 9:21 PM
> Subject: [ntdev] RE: Origin of IRP?
>
>
> you can get a pointer to the thread that issued the request out of the
> IRP, but there’s nothing in the request which points to the process.
> There is information about the thread & process in the thread data
> structure but that should be considered opaque so you may not want to
> access it. There doesn’t appear to be a DDK exported method for getting
> the CLIENT_ID structure from a thread pointer.
>
> knowing which application send an IO can be helpful for logging purposes
> if that’s your goal, but please don’t try using it to “secure” your
> driver. For example, allowing any process named “myapp.exe” to read
> restricted portions of the disk is really never going to be secure since
> anyone can launch a binary named “myapp.exe”.
>
> -p
>
>
>
> -----Original Message-----
> From: Omri [mailto:xxxxx@verizon.net]
> Sent: Monday, September 23, 2002 11:12 AM
> To: NT Developers Interest List
> Subject: [ntdev] Origin of IRP?
>
>
> Is there a way to identify the usermode application that was the IRP
> initiator. for instance identify application that request read/write
> from disks?
>
> Omri
>
> —
> You are currently subscribed to ntdev as: xxxxx@microsoft.com To
> unsubscribe send a blank email to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>
>