Fast I/O support in a filter driver

NTFSD
1

Hello!

I am writing a filter driver that monitors some file system events. My driver supports basically Fast I/O. I mean it just passes the requests to the lower driver.
Suppose I want for example to deny a file write in certain circumstances, and I check the write IRP, is it possible that some write will not be stopped because of Fast I/O write?

Thanks!

2

Not enough research, it appears. The question is N/A. There is an answer,
but either Yes or No is incorrect. Once a file is opened for write access,
you must allow writes. Any other solution will not work in all cases or
even a majority of the cases.

wrote in message news:xxxxx@ntfsd…
> Hello!
>
> I am writing a filter driver that monitors some file system events. My
> driver supports basically Fast I/O. I mean it just passes the requests to
> the lower driver.
> Suppose I want for example to deny a file write in certain circumstances,
> and I check the write IRP, is it possible that some write will not be
> stopped because of Fast I/O write?
>
> Thanks!
>

3

Ok. I will explain myself in another way. I checked what is happening with IRP’s and Fas I/O using FileSpy, and noticed that every time I write or read from a file, Fast I/O fails. I am reading and writing to a network share. Will it always fail, or it will work under certain circumstances?

4

You cannot deny the file write if the file was opened with WRITE_DATA bit
in DesiredAccess.

You must fail CREATE instead.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> Hello!
>
> I am writing a filter driver that monitors some file system events. My driver
supports basically Fast I/O. I mean it just passes the requests to the lower
driver.
> Suppose I want for example to deny a file write in certain circumstances, and
I check the write IRP, is it possible that some write will not be stopped
because of Fast I/O write?
>
> Thanks!
>

5

Hi Maxim,

You cannot deny the file write if the file was opened with WRITE_DATA bit
in DesiredAccess.

You must fail CREATE instead.

Agreed that we should NOT FAIL the request.

But I have a question.

I had asked this in a different thread also.

First of all, can DuplicateHandle be used to duplicate a file handle across users?

And here is the scenario:

Suppose a filter gets and saves the User SID in IRP_MJ_CREATE and uses that to identify the user in the further IRPs that it receives .

Let’s assume for time being that calls are NONCACHED. Basically, the file is opened with FILE_NO_INTERMEDIATE_BUFFERING flag.

Let’s say a process P1 (User: U1) opens a file. A FILE_OBJECT is created. The filter associates the User SID with this FILE_OBJECT.

What if the process (P1) calls DuplicateHandle to create a handle and give it to some other process , P2(User:U2).

Now we have two handles referring to the same FILE_OBJECT.

Now, if P2 issues a Write call, the Write IRP will come in context of User U2. However, the filter will report it as U1.

What should be done in this case?

Regards,
Ayush Gupta.

6

>First of all, can DuplicateHandle be used to duplicate a file handle across
users?

No. The file object remains the same, and FSD is not notified on
DuplicateHandle. You cannot increase GrantedAccess with DuplicateHandle.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

7

My question was not which IRP I should stop. My question was if there is a possibility that no IRP will be generated at all and all the write operation will be done through Fast I/O? Especially when filtering LanManRedirector.