Not seeing all IRP_MJ_CREATE calls?

NTFSD
1

Probably just a misunderstanding but… My file system filter does not see
all the IRP_MJ_CREATE calls I think that it should. This is the
scenario…

  1. Open a text file in NotePad (File Mapping, I know).
  2. My filter sees the initial create call and subsequent reads (does some
    decryption).
  3. Close NotePad.
  4. My filter sees the CLEANUP, but no close (still mapped).
  5. Open the file in some other app (type.exe, edit.exe).

At step 5 my filter sees no IRP_MJ_CREATE and the content file is
successfully accessed by the other app without neither the say-so nor
decryption services of my filter.

Is the system re-using a handle from the still mapped file image? How can
I be sure to intercept all subsequent file opens/reads by any app
attempting to access a file that has once been memory mapped by the
system?

It seems this is a fundamental requirement for a decrypting filter, no?

2

There MUST be a create issued by that other app in order for it to
acquire a handle to the file. There are no exceptions. Obviously your
filter is seeing tons of creates for lots of files all the time. How are
you determining whether a given create is for ‘your’ file?

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill
Sent: Friday, January 24, 2003 7:33 AM
To: File Systems Developers
Subject: [ntfsd] Not seeing all IRP_MJ_CREATE calls?

Probably just a misunderstanding but… My file system filter
does not see all the IRP_MJ_CREATE calls I think that it
should. This is the scenario…

  1. Open a text file in NotePad (File Mapping, I know).
  2. My filter sees the initial create call and subsequent
    reads (does some decryption). 3. Close NotePad. 4. My
    filter sees the CLEANUP, but no close (still mapped). 5.
    Open the file in some other app (type.exe, edit.exe).

At step 5 my filter sees no IRP_MJ_CREATE and the content
file is successfully accessed by the other app without
neither the say-so nor decryption services of my filter.

Is the system re-using a handle from the still mapped file
image? How can I be sure to intercept all subsequent file
opens/reads by any app attempting to access a file that has
once been memory mapped by the system?

It seems this is a fundamental requirement for a decrypting
filter, no?

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

3

Of course you are right, Nick. Sometimes we need to be told what we
already know before we go looking for the “real” solution. I was
filtering files by name and tracking them by open FCB/fileObject
associations - no problem, but I had a logic bug that prevented me from
filtering properly when my test harness code was shut down improperly.

Problem resolved. Thanks for the reminder about “no exceptions”.

There MUST be a create issued by that other app in order for it to
acquire a handle to the file. There are no exceptions. Obviously your
filter is seeing tons of creates for lots of files all the time. How are
you determining whether a given create is for ‘your’ file?

  • Nicholas Ryan
4

Be aware that on XP there is IoCreateFileSpecifyDeviceObjectHint(…) (docu
in IFS Kit), so some kernel device drivers can bypass your FSFD by sending
IRP_MJ_CREATE directly to target DO. It is also possible to use “Shadow
Device Object” (search on FAQ on www.osr.com) to open a file and bypass FS
filter drivers. I also recommend that you search through archives on this
list, since there was already discussion about who and how open file stream
and bypass other FS filter drivers on chain.
WBR Primoz

-----Original Message-----
From: Bill [mailto:xxxxx@endwell.net]
Sent: Monday, January 27, 2003 6:21 AM
To: File Systems Developers
Subject: [ntfsd] RE: Not seeing all IRP_MJ_CREATE calls?

Of course you are right, Nick. Sometimes we need to be told
what we already know before we go looking for the “real”
solution. I was filtering files by name and tracking them by
open FCB/fileObject associations - no problem, but I had a
logic bug that prevented me from filtering properly when my
test harness code was shut down improperly.

Problem resolved. Thanks for the reminder about “no exceptions”.

> There MUST be a create issued by that other app in order for it to
> acquire a handle to the file. There are no exceptions.
Obviously your
> filter is seeing tons of creates for lots of files all the
time. How
> are you determining whether a given create is for ‘your’ file?
>
> - Nicholas Ryan

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