Suspent IRP, call User app, then proceed?

OSR_Community_User · September 7, 2005, 8:38am

Hello everyone,

What would be the most efficient way to suspend an IRP? I need this filter
driver to watch for specific file names (ex. somefile.exe). When a create
for ‘somefile.exe’ is detected, I need the driver to halt and have a
usermode exe validate it’s digital signature.

“somefile.exe” should have a valid certificate embedded in it, after the
cert along with it’s CA chain is validated, the user app. should signal the
driver to allow the file to be opened (thus allowing the original IRP to
complete).

Any ideas on the most efficient way to do this?

Matt

Baja_Mani · September 7, 2005, 8:58am

No need to suspend the IRP. In the dispatch path, signal your usermode exe
to validate somefile.exe and wait for it (in the same path) till the
validation is over. After validation the user mode exe signals an event and
unblocks the dispatch path.

Mani

“Matt Martin” wrote in message news:xxxxx@ntfsd…
> Hello everyone,
>
> What would be the most efficient way to suspend an IRP? I need this filter
> driver to watch for specific file names (ex. somefile.exe). When a create
> for ‘somefile.exe’ is detected, I need the driver to halt and have a
> usermode exe validate it’s digital signature.
>
> “somefile.exe” should have a valid certificate embedded in it, after the
> cert along with it’s CA chain is validated, the user app. should signal
the
> driver to allow the file to be opened (thus allowing the original IRP to
> complete).
>
> Any ideas on the most efficient way to do this?
>
> Matt
>
>

OSR_Community_User · September 7, 2005, 9:11am

Hi Matt,

Well, I would suggest the following:

Communicate with user mode using Async IO and pending IRPs, hence, the user mode app will ‘post’ IRPs through ReadFile, DeviceIoControl, … to your driver, on the driver use a Cancelable queue to queue the IRPs ( see the cancel.c DDK sample for that ), upon queuing an IRP set the IRP as pending and return STATUS_PENDING to user mode, this will enable your app to manage a queue of requests being ‘answered’ asynchronously, to efficiently handle the requests in user-mode use an IO Completion port.
For the file access being authenticated ( the suspended IRP ):

Get a pending IRP request from the IRP queue ( using the mechanism described in [1] ), fill it with what ever authentication query you want and ‘send it’ to the user using IoCompleteRequest, after calling ‘IoCompleteRequest’ block the executing thread and wait for an answer from the user ( using a common event or so ), set a timeout threshold to prevent the system from hanging…

I hope this is clear enough…

Naddav.

Matt Martin wrote:
Hello everyone,

What would be the most efficient way to suspend an IRP? I need this filter
driver to watch for specific file names (ex. somefile.exe). When a create
for ‘somefile.exe’ is detected, I need the driver to halt and have a
usermode exe validate it’s digital signature.

“somefile.exe” should have a valid certificate embedded in it, after the
cert along with it’s CA chain is validated, the user app. should signal the
driver to allow the file to be opened (thus allowing the original IRP to
complete).

Any ideas on the most efficient way to do this?

Matt

—
Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

amitr0-2 · September 7, 2005, 9:24am

>What would be the most efficient way to suspend an IRP? I need this filter

driver to watch for specific file names (ex. somefile.exe). When a create
for ‘somefile.exe’ is detected, I need the driver to halt and have a
usermode exe validate it’s digital signature.

You do not need to suspend any IRP. In dispatch, signal the usermode
application
to do some validation for somefile.exe and wait for it till the
validation process is over. After validating the usermode app can singal an
event to
unblocks the dispatch path.

Developer

PS:- What nadav says is also another solution, infact may be better.

OSR_Community_User · September 7, 2005, 9:37am

> In dispatch, signal the usermode application

to do some validation for somefile.exe and wait for it till the

Don’t forget that you’ll get the create IRP for somefile.exe again,
when the usermode app will check the file. You must handle this
case correctly to prevent deadlock.

L.

amitr0-2 · September 7, 2005, 9:47am

yes, I forgot that point.

also, where exactly do you plan to attch your driver?

OSR_Community_User · September 8, 2005, 7:36am

I see that… How could I handle a second create for the same file (somefile.exe)???

Would using a static Boolean value solve this problem?

The first IRP_Create sets a Boolean value to true and sends a message to the usermode app and waits.
The second IRP_Create is received for the certificate check(generated by user app); in a switch structure, based upon the Boolean value, the second irp is passed down to the next lower driver.
The Boolean value is cleared(reset), return status success.

Is there a more elegant way to handle the re-entry? Would the above technique even work? Is there a way to prevent re-entry and still do the same thing?

I intend for this driver to sit at the very top of the stack.

Naddav, sorry but I got a little confused in your response. I’ve re-read it several times, I think I need to re-read it several more times… Thanks though, perhaps once I get some sleep and can think a little more clearly and I’ll understand it fully.

Matt

----- Original Message -----
From: Ladislav Zezula
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 07, 2005 8:30 AM
Subject: Re: [ntfsd] Suspent IRP, call User app, then proceed?

In dispatch, signal the usermode application
> to do some validation for somefile.exe and wait for it till the

Don’t forget that you’ll get the create IRP for somefile.exe again,
when the usermode app will check the file. You must handle this
case correctly to prevent deadlock.

L.

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Don_Burn_1 · September 8, 2005, 7:50am

Actually, this is a pretty poor way. You should have a mechanism for your
control application to identify itself to the filter. Then requests from
the application are passed through. A boolean will not work, how do you
know if process A tries to access the file, then before the control app gets
control, process B tries to access the file, with a boolean B gets through,
and your control application blocks.

You need to be thinking about multiple accesses, and probably multiple files
(unless things are very special purpose). Remember, that with dual core 8
way systems will become common here, and expect to see much cheaper 16
processor or more. If you don’t consider a high degree of concurrency it
will bight you.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Matt Martin” wrote in message news:xxxxx@ntfsd…
I see that… How could I handle a second create for the same file
(somefile.exe)???

Would using a static Boolean value solve this problem?

1. The first IRP_Create sets a Boolean value to true and sends a message to
the usermode app and waits.
2. The second IRP_Create is received for the certificate check(generated by
user app); in a switch structure, based upon the Boolean value, the second
irp is passed down to the next lower driver.
3. The Boolean value is cleared(reset), return status success.

Is there a more elegant way to handle the re-entry? Would the above
technique even work? Is there a way to prevent re-entry and still do the
same thing?

I intend for this driver to sit at the very top of the stack.

Naddav, sorry but I got a little confused in your response. I’ve re-read it
several times, I think I need to re-read it several more times… Thanks
though, perhaps once I get some sleep and can think a little more clearly
and I’ll understand it fully.

Matt

----- Original Message -----
From: Ladislav Zezula
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 07, 2005 8:30 AM
Subject: Re: [ntfsd] Suspent IRP, call User app, then proceed?

> In dispatch, signal the usermode application
> to do some validation for somefile.exe and wait for it till the

Don’t forget that you’ll get the create IRP for somefile.exe again,
when the usermode app will check the file. You must handle this
case correctly to prevent deadlock.

L.

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · September 8, 2005, 7:51am

> I intend for this driver to sit at the very top of the stack.

Hehehe. How can you be so sure ?
What if anyone runs Filemon after your driver’s been installed ?

L.

Don_Burn_1 · September 8, 2005, 7:56am

I missed that one, good point Ladislav. To the OP, you can never assume
that you are the top of the stack, this is a great way to mess up.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> I intend for this driver to sit at the very top of the stack.

Hehehe. How can you be so sure ?
What if anyone runs Filemon after your driver’s been installed ?

L.

amitr0-2 · September 8, 2005, 7:57am

>I intend for this driver to sit at the very top of the stack.

There is no way to guarentee that your driver *will* be the lasto fo the
mohicans!!! And you should never assume that.

OSR_Community_User · September 8, 2005, 8:23am

Don,

Actually there is only one process that would attempt to open “somefile.exe”
(with the exception of explorer.exe; I see your potential error occurring
here if explorer tried to open it).

“You should have a mechanism for your control application to identify itself
to the filter.”

I can not disagree with the above statement you made, but what exactly do
you mean by it? Do you mean instead of using a Boolean expression, instead
the control application should signal the driver to dis-engage the
“somefile.exe” filter while the certificate validate routine is running and
then re-engage it after the check is done???

“What if anyone runs Filemon after your driver’s been installed ?”

Well L., I guess it wouldn’t be at the top of the stack anymore… Oh well,
Sh*t Happens…

Matt
----- Original Message -----
From: “Don Burn”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, September 08, 2005 6:50 AM
Subject: Re:[ntfsd] Suspent IRP, call User app, then proceed?

> Actually, this is a pretty poor way. You should have a mechanism for your
> control application to identify itself to the filter. Then requests from
> the application are passed through. A boolean will not work, how do you
> know if process A tries to access the file, then before the control app
> gets control, process B tries to access the file, with a boolean B gets
> through, and your control application blocks.
>
> You need to be thinking about multiple accesses, and probably multiple
> files (unless things are very special purpose). Remember, that with dual
> core 8 way systems will become common here, and expect to see much cheaper
> 16 processor or more. If you don’t consider a high degree of concurrency
> it will bight you.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Matt Martin” wrote in message
> news:xxxxx@ntfsd…
> I see that… How could I handle a second create for the same file
> (somefile.exe)???
>
> Would using a static Boolean value solve this problem?
>
> 1. The first IRP_Create sets a Boolean value to true and sends a message
> to the usermode app and waits.
> 2. The second IRP_Create is received for the certificate check(generated
> by user app); in a switch structure, based upon the Boolean value, the
> second irp is passed down to the next lower driver.
> 3. The Boolean value is cleared(reset), return status success.
>
> Is there a more elegant way to handle the re-entry? Would the above
> technique even work? Is there a way to prevent re-entry and still do the
> same thing?
>
> I intend for this driver to sit at the very top of the stack.
>
> Naddav, sorry but I got a little confused in your response. I’ve re-read
> it several times, I think I need to re-read it several more times…
> Thanks though, perhaps once I get some sleep and can think a little more
> clearly and I’ll understand it fully.
>
> Matt
>
> ----- Original Message -----
> From: Ladislav Zezula
> To: Windows File Systems Devs Interest List
> Sent: Wednesday, September 07, 2005 8:30 AM
> Subject: Re: [ntfsd] Suspent IRP, call User app, then proceed?
>
>
> > In dispatch, signal the usermode application
> > to do some validation for somefile.exe and wait for it till the
>
> Don’t forget that you’ll get the create IRP for somefile.exe again,
> when the usermode app will check the file. You must handle this
> case correctly to prevent deadlock.
>
> L.
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Don_Burn_1 · September 8, 2005, 8:35am

First, you can’t be sure no one else will not try to open “somefile.exe”,
virus scanners, backup utilities, advanced search, the list goes on. As far
as the indicator, your control application if it sends an IRP to wait for a
request will identify itself, use IoGetRequestorProcess to store away the
process pointer (be sure to handle the case of cancel due to process
termination). Then in create if a request comes in from your control
application, you can detect it by checking the process, and not block.

You have to design your code to be anywhere in the stack, if you don’t think
there will be another filter above you, sorry it is going to happen a lot.
Crashing or malfunctioning is not the right answer.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Matt Martin” wrote in message news:xxxxx@ntfsd…
> Don,
>
> Actually there is only one process that would attempt to open
> “somefile.exe” (with the exception of explorer.exe; I see your potential
> error occurring here if explorer tried to open it).
>
> “You should have a mechanism for your control application to identify
> itself to the filter.”
>
> I can not disagree with the above statement you made, but what exactly do
> you mean by it? Do you mean instead of using a Boolean expression, instead
> the control application should signal the driver to dis-engage the
> “somefile.exe” filter while the certificate validate routine is running
> and then re-engage it after the check is done???
>
> “What if anyone runs Filemon after your driver’s been installed ?”
>
> Well L., I guess it wouldn’t be at the top of the stack anymore… Oh
> well, Sh*t Happens…
>
>
> Matt
> ----- Original Message -----
> From: “Don Burn”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Thursday, September 08, 2005 6:50 AM
> Subject: Re:[ntfsd] Suspent IRP, call User app, then proceed?
>
>
>> Actually, this is a pretty poor way. You should have a mechanism for
>> your control application to identify itself to the filter. Then requests
>> from the application are passed through. A boolean will not work, how do
>> you know if process A tries to access the file, then before the control
>> app gets control, process B tries to access the file, with a boolean B
>> gets through, and your control application blocks.
>>
>> You need to be thinking about multiple accesses, and probably multiple
>> files (unless things are very special purpose). Remember, that with dual
>> core 8 way systems will become common here, and expect to see much
>> cheaper 16 processor or more. If you don’t consider a high degree of
>> concurrency it will bight you.
>>
>>
>> –
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>>
>> “Matt Martin” wrote in message
>> news:xxxxx@ntfsd…
>> I see that… How could I handle a second create for the same file
>> (somefile.exe)???
>>
>> Would using a static Boolean value solve this problem?
>>
>> 1. The first IRP_Create sets a Boolean value to true and sends a message
>> to the usermode app and waits.
>> 2. The second IRP_Create is received for the certificate check(generated
>> by user app); in a switch structure, based upon the Boolean value, the
>> second irp is passed down to the next lower driver.
>> 3. The Boolean value is cleared(reset), return status success.
>>
>> Is there a more elegant way to handle the re-entry? Would the above
>> technique even work? Is there a way to prevent re-entry and still do the
>> same thing?
>>
>> I intend for this driver to sit at the very top of the stack.
>>
>> Naddav, sorry but I got a little confused in your response. I’ve re-read
>> it several times, I think I need to re-read it several more times…
>> Thanks though, perhaps once I get some sleep and can think a little more
>> clearly and I’ll understand it fully.
>>
>> Matt
>>
>> ----- Original Message -----
>> From: Ladislav Zezula
>> To: Windows File Systems Devs Interest List
>> Sent: Wednesday, September 07, 2005 8:30 AM
>> Subject: Re: [ntfsd] Suspent IRP, call User app, then proceed?
>>
>>
>> > In dispatch, signal the usermode application
>> > to do some validation for somefile.exe and wait for it till the
>>
>> Don’t forget that you’ll get the create IRP for somefile.exe again,
>> when the usermode app will check the file. You must handle this
>> case correctly to prevent deadlock.
>>
>> L.
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
>> ‘’
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@comcast.net
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

OSR_Community_User · September 8, 2005, 8:36am

> I can not disagree with the above statement you made, but what exactly do

you mean by it?

if(PsGetCurrentProcessId() == MySecretCheckedProcessId)
{
return MyFilterPassIrpThrough(DeviceObject, Irp);
};

L.

Don_Burn_1 · September 8, 2005, 8:51am

You can’t rely on this, if my filter uses a worker thread and sits above
your filter this does not work. Use IoGetRequestorProcess to be safe.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> I can not disagree with the above statement you made, but what exactly do
>> you mean by it?
>
> if(PsGetCurrentProcessId() == MySecretCheckedProcessId)
> {
> return MyFilterPassIrpThrough(DeviceObject, Irp);
> };
>
>
> L.
>
>

OSR_Community_User · September 8, 2005, 8:57am

Hey guys, Thanks, I see where you’ll are going with this. I appreciate the
help a lot.

Matt

----- Original Message -----
From: “Don Burn”
Newsgroups: ntfsd
To: “Windows File Systems Devs Interest List”
Sent: Thursday, September 08, 2005 7:50 AM
Subject: Re:[ntfsd] Re:Suspent IRP, call User app, then proceed?

> You can’t rely on this, if my filter uses a worker thread and sits above
> your filter this does not work. Use IoGetRequestorProcess to be safe.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>>> I can not disagree with the above statement you made, but what exactly
>>> do you mean by it?
>>
>> if(PsGetCurrentProcessId() == MySecretCheckedProcessId)
>> {
>> return MyFilterPassIrpThrough(DeviceObject, Irp);
>> };
>>
>>
>> L.
>>
>>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com

OSR_Community_User · September 8, 2005, 12:03pm

The approach I suggest for services and filters to identify each other
is to use built-in Windows security. The filter can read a security
descriptor from its registry key and apply it to the control device
object. By establishing access to the CDO so that a specific account
can access it (and not open to “Administrators” or other well know user
or group SIDs) and then having the service run under that same account,
you know when the CDO is opened it must be an authorized service.

This isn’t foolproof and it can be compromised by anyone who can
compromise the TCB, but it is another “layer” that must be identified
and penetrated in order to take advantage of your service (and that
significantly lowers the likelihood of attack on you). It is also
relatively easy to implement and provides significant protection with
relatively low effort - and low risk of “doing it wrong” because you
aren’t implementing new security policy (just using existing OS-provided
mechanism).

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, September 08, 2005 7:50 AM
To: ntfsd redirect
Subject: Re:[ntfsd] Suspent IRP, call User app, then proceed?

Actually, this is a pretty poor way. You should have a mechanism for
your
control application to identify itself to the filter. Then requests
from
the application are passed through. A boolean will not work, how do you

know if process A tries to access the file, then before the control app
gets
control, process B tries to access the file, with a boolean B gets
through,
and your control application blocks.

You need to be thinking about multiple accesses, and probably multiple
files
(unless things are very special purpose). Remember, that with dual core
8
way systems will become common here, and expect to see much cheaper 16
processor or more. If you don’t consider a high degree of concurrency
it
will bight you.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Matt Martin” wrote in message
news:xxxxx@ntfsd…
I see that… How could I handle a second create for the same file
(somefile.exe)???

Would using a static Boolean value solve this problem?

1. The first IRP_Create sets a Boolean value to true and sends a message
to
the usermode app and waits.
2. The second IRP_Create is received for the certificate check(generated
by
user app); in a switch structure, based upon the Boolean value, the
second
irp is passed down to the next lower driver.
3. The Boolean value is cleared(reset), return status success.

Is there a more elegant way to handle the re-entry? Would the above
technique even work? Is there a way to prevent re-entry and still do the

same thing?

I intend for this driver to sit at the very top of the stack.

Naddav, sorry but I got a little confused in your response. I’ve re-read
it
several times, I think I need to re-read it several more times…
Thanks
though, perhaps once I get some sleep and can think a little more
clearly
and I’ll understand it fully.

Matt

----- Original Message -----
From: Ladislav Zezula
To: Windows File Systems Devs Interest List
Sent: Wednesday, September 07, 2005 8:30 AM
Subject: Re: [ntfsd] Suspent IRP, call User app, then proceed?

> In dispatch, signal the usermode application
> to do some validation for somefile.exe and wait for it till the

Don’t forget that you’ll get the create IRP for somefile.exe again,
when the usermode app will check the file. You must handle this
case correctly to prevent deadlock.

L.

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Manish_Sharma · September 9, 2005, 1:36am

Hi Amitrajitb,
I am also working on similar project like this i did it in the same way
which you described but the problem for me is ,suppose a folder is there
which contain “somefile.exe” and if i right click it and copy it and then
try to paste it then for this case(only) i am getting many irp in create. so
till the time my driver is waiting for the user mode application to complete
its processing i am getting many request in my usermode application from
driver so system is saying access denied(due to sharing) what may be the
reason??
any help will be helpful for me
Manish

On 9/7/05, Developer wrote:
>
> >What would be the most efficient way to suspend an IRP? I need this
> filter
> >driver to watch for specific file names (ex. somefile.exe). When a create
> >for ‘somefile.exe’ is detected, I need the driver to halt and have a
> >usermode exe validate it’s digital signature.
>
> You do not need to suspend any IRP. In dispatch, signal the usermode
> application
> to do some validation for somefile.exe and wait for it till the
> validation process is over. After validating the usermode app can singal
> an event to
> unblocks the dispatch path.
>
>
>
>
>
>
> - Developer
>
> PS:- What nadav says is also another solution, infact may be better.
> — Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17 You are currently subscribed
> to ntfsd as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank
> email to xxxxx@lists.osr.com

–
Manish K. Sharma

Life is Small and Lots of Things to Learn
Lets Share the Knowledge

OSR_Community_User · September 14, 2005, 6:04am

I don’t think IoGetRequestorProcess is reliable for this purpose, because
(among other things) IoGetRequestorProcess will return the process that the
thread is currently attached to on XP. So, if the thread that originated the
IRP is attached to a different process at the time of call to
IoGetRequestorProcess than when initiating the IRP you’ll get the wrong
process returned.
Note that kernel-mode primitives used by such as e.g. CopyHandle and
ReadProcessMemory are implemented in terms of KeStackAttachProcess, so if
the originating thread is executing freely in userland, as is the case for
async reads and writes, it’s not at all far-fetched to see this.

On 9/8/05, Don Burn wrote:
>
> You can’t rely on this, if my filter uses a worker thread and sits above
> your filter this does not work. Use IoGetRequestorProcess to be safe.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
> “Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
> >> I can not disagree with the above statement you made, but what exactly
> do
> >> you mean by it?
> >
> > if(PsGetCurrentProcessId() == MySecretCheckedProcessId)
> > {
> > return MyFilterPassIrpThrough(DeviceObject, Irp);
> > };
> >
> >
> > L.
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

–
Life is what happens to you while you’re busy making other plans
– John Lennon

OSR_Community_User · September 14, 2005, 7:05am

> I don’t think IoGetRequestorProcess is reliable for this purpose,

because (among other things) IoGetRequestorProcess will
return the process that the thread is currently attached to on XP.

I looked at IoGetRequestorProcess dissassembly,
and ot seems to be

PEPROCESS IoGetRequestorProcess(PIRP Irp)
{
if(Irp->Tail.Overlay.Thread != NULL)
return Irp->Tail.Overlay.Thread->ThreadsProcess;
return NULL;
}

So it just takes the ETHREAD pointer from the IRP and gets the EPROCESS
pointer from it.

L.