Deny File Access in Post-Create

NTFSD
1

Hi All,

I am writing sample mini-filter driver in which i am denying access to a file in Post-create using FltCancelFileOpen(). For Performance purpose, i want to deny it in Post-create only.

Here is the Pseudo code:

if (my file)
{
FltCancelFileOpen(FltObjects->Instance,FltObjects->FileObject);
Data->IoStatus.Status = STATUS_ACCESS_DENIED;
Data->IoStatus.Information = 0;
}

return FLT_POSTOP_FINISHED_PROCESSING;

Does denying file access in post-create can create some problems ?

Any inputs are appreciated.

Thanks
Mahesh

2

> Does denying file access in post-create can create some problems ?

Have you considered the case when IRP_MJ_CREATE comes with the following flags in CreateDisposition

  1. FILE_SUPERSEDE
  2. FILE_OVERWRITE

The contents of the file are already lost till Post Create…

Regards,
Ayush Gupta

3

>I am writing sample mini-filter driver in which i am denying access to a file in Post-create using >FltCancelFileOpen(). For Performance purpose, i want to deny it in Post-create only.

Here is the Pseudo code:

if (my file)
{
FltCancelFileOpen(FltObjects->Instance,FltObjects->FileObject);
Data->IoStatus.Status = STATUS_ACCESS_DENIED;
Data->IoStatus.Information = 0;
}

return FLT_POSTOP_FINISHED_PROCESSING;

Does denying file access in post-create can create some problems ?

This may depend on WHY you want to deny the file open.

For example, if you are writing an antivirus minifilter similar to the scanner minifilter sample, and you want to deny the opening of an infected file, this approach is fine. You can wait till the post create. Then scan (read) the file using the file object you have got in the post create. In case it is infected, cancel the file open using FltCancelFileOpen.

Take another case where you want to deny file open for a process. Let us say that you want to allow the file open when it is accessed by some specific processes and deny for all other processes.
In this case, you should do the stuff in the PreCreate. Suppose a process opens a file with FILE_SUPERSEDE or FILE_OVERWRITE or FILE_OVERWRITE_IF flag, and you wanted to deny the file open so that the process is not able to make any modification; doing the check in Post Create would be useless. (The contents have already been lost… :P). Do the checks in Pre Create here…

There may be n no. of other cases also…

Regards,
Ayush Gupta

4

Hi,

Ayush, Thanks for your valuable inputs.

It is mentioned in IFS Kit documentation that FltCancelFileOpen must be called before any handles are created for the file otherwise it is not safe to call it.

Does the above statement is resembling the following scenario.
Suppose one application has already opened the file and i want to deny the opening of same file to some other application in Post-Create.
Is it safe to do such thing, according to the documentation ?

Thanks
Mahesh

5

Mahesh,

The scenerio you described should work fine. FltCancelFileOpen stops the
Create process - which is what
generates handles (file objects, after pre and post have finished). As you
know, there could be numerous
creates for a given file, therefor, you could call it multiple times. You
just don’t want to call that function after
the create operation has finished (post op), obviously that could have
disasterous effects.

Storing a stream context with your desired app’s PID would allow you to
filter apps out. All calls into your
create handler will be in the context of the caller, both pre and post - so
this should work just fine for you.

Good Luck,

Matt

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, January 01, 2008 6:14 AM
Subject: RE:[ntfsd] Deny File Access in Post-Create

> Hi,
>
> Ayush, Thanks for your valuable inputs.
>
> It is mentioned in IFS Kit documentation that FltCancelFileOpen must be
> called before any handles are created for the file otherwise it is not
> safe to call it.
>
> Does the above statement is resembling the following scenario.
> Suppose one application has already opened the file and i want to deny
> the opening of same file to some other application in Post-Create.
> Is it safe to do such thing, according to the documentation ?
>
>
> Thanks
> Mahesh
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

6

Hi Mahesh,

Is it safe to do such thing, according to the documentation ?

There are few more lines in the documentation:

" Note that FltCancelFileOpen does not undo any modifications to the file. For example, FltCancelFileOpen does not delete a newly created file or restore a file that was overwritten or superseded to its previous state."

And according to this, you will be able to deny the opening of the file. *BUT YOU WONT BE ABLE TO GUARANTEE THAT THE APPLICATION HAS NOT MODIFIED THE CONTENTS*. To ensure that this does not happen, do the stuff in PreCallback of IRP_MJ_CREATE.

Regards,
Ayush Gupta

7

Hi Matt,

Storing a stream context with your desired app’s PID would allow you to
filter apps out. All calls into your
create handler will be in the context of the caller, both pre and post - so
this should work just fine for you.

How will the stream context help anyways?
I suppose you can associate a stream context only after the IRP_MJ_CREATE has been processed by the file system; basically in your PostCallback routine for IRP_MJ_CREATE or sometime after that.
How will STORING A STREAM CONTEXT help the OP to filter apps out??

You just don’t want to call that function after the create operation has finished (post op), obviously that could have disasterous effects.

If the OP WISHES to use FltCancelFileOpen, he must do that in PostCallback of IRP_MJ_CREATE ONLY.

However, FltCancelFileOpen approach is NOT good for what the OP wants to develop.

Regards,
Ayush Gupta

8

RE: RE:[ntfsd] Deny File Access in Post-CreateHello Ayush,

Regarding the stream context, I was suggesting that after his logic determines if a process should be allowed
or denied access to a file, it should use FltGetRequestorProcessID and store that PID in a context to aleviate
extra processing. Therefor, in the future this would be an easy check opposed to running threw all the logic
required (whatever that may be) to determine if each create should be allowed or denied.

Regarding my coments about FltCancelFileOpen, I was responding to his query of ‘can FltCancelFIleOpen be called
for an already open file?’.

I do agree with you about calling FltCancelFileOpen in post create isn’t the best solution for a simple access check,
given the two create options you mentioned earlier in this thread. Therefor, he would have to check the file in pre-create,
but that leaves me wondering, ‘will filter manager allow you to cancel an IRP_CREATE in the precreate callback?’.

From my understanding, in a legacy filter you could cancel a create in dispatch by setting the apporpriate error in
IRP->IOSTATUS.status, call IoCompleteRequest, and then return the error from the dispatch handler… (something like that).

In a minifilter - how would this be done? Can it be done, surely it must. If not, I suppose one ‘elegant’ way would be
to reparse it to the ‘pits of hell’ and let fltmgr and the IO manager figure it out and clean up (just a wild idea that poped to mind).

Anyhow, Happy Belated New Year,

Matt

----- Original Message -----
From: Ayush Gupta
To: Windows File Systems Devs Interest List
Sent: Wednesday, January 02, 2008 9:34 PM
Subject: RE: RE:[ntfsd] Deny File Access in Post-Create

Hi Matt,

Storing a stream context with your desired app’s PID would allow you to

filter apps out. All calls into your

create handler will be in the context of the caller, both pre and post - so

this should work just fine for you.

How will the stream context help anyways?

I suppose you can associate a stream context only after the IRP_MJ_CREATE has been processed by the file system; basically in your PostCallback routine for IRP_MJ_CREATE or sometime after that.

How will STORING A STREAM CONTEXT help the OP to filter apps out??

You just don’t want to call that function after the create operation has finished (post op), obviously that could have disasterous effects.

If the OP WISHES to use FltCancelFileOpen, he must do that in PostCallback of IRP_MJ_CREATE ONLY.

However, FltCancelFileOpen approach is NOT good for what the OP wants to develop.

Regards,

Ayush Gupta

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

9

Hello Mathew,

Regarding the stream context, I was suggesting that after his logic determines if a process should be allowed

or denied access to a file, it should use FltGetRequestorProcessID and store that PID in a context to aleviate

extra processing. Therefor, in the future this would be an easy check opposed to running threw all the logic

required (whatever that may be) to determine if each create should be allowed or denied.

I still do not understand how you will associate a stream context. You CANNOT associate a stream context before the Post Callback for IRP_MJ_CREATE. And since you are going to deny in pre callback itself, you won’t receive a Post Callback for it.

will filter manager allow you to cancel an IRP_CREATE in the precreate callback?.

Yes. You have to do the following to cancel the IRP:

  1. IoStatus.Status = STATUS_ACCESS_DENIED (or other Failure status code).

  2. Return FLT_PREOP_COMPLETE.

And happy new year to you too. J

Regards,

Ayush Gupta

10

RE: RE:[ntfsd] Deny File Access in Post-CreateAyush,

That is true, context must be set/get in post operations (with creates). Although they can be allocated in pre-create and passed via
the CompletionContext, that obviously wouldn’t be very helpful here. Those statements about the stream context, I meant
to imply an association with my response regarding FltCancelFileOpen. Sorry for the communication error…

Thanks for that info, I’ll have to try that out sometime. From looking at the docs, I see FltSetCallBackData ISN’T necessary,
I was thinking it might be… I see the Status field is exempted.

Don’t work to hard,

Matt

----- Original Message -----
From: Ayush Gupta
To: Windows File Systems Devs Interest List
Sent: Thursday, January 03, 2008 7:02 AM
Subject: RE: RE:[ntfsd] Deny File Access in Post-Create

Hello Mathew,

Regarding the stream context, I was suggesting that after his logic determines if a process should be allowed

or denied access to a file, it should use FltGetRequestorProcessID and store that PID in a context to aleviate

extra processing. Therefor, in the future this would be an easy check opposed to running threw all the logic

required (whatever that may be) to determine if each create should be allowed or denied.

I still do not understand how you will associate a stream context. You CANNOT associate a stream context before the Post Callback for IRP_MJ_CREATE. And since you are going to deny in pre callback itself, you won’t receive a Post Callback for it.

will filter manager allow you to cancel an IRP_CREATE in the precreate callback?.

Yes. You have to do the following to cancel the IRP:

  1. IoStatus.Status = STATUS_ACCESS_DENIED (or other Failure status code).

  2. Return FLT_PREOP_COMPLETE.

And happy new year to you too. J

Regards,

Ayush Gupta

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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