Hi all
Could anyone tell me please how can a File System Filter detect the moment
an application calls CreateFileMapping() on a file?
Thanx in advance
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> Could anyone tell me please how can a File System Filter detect the moment
an application calls CreateFileMapping() on a file?
AcquireFileForNtCreateSection fastIO callback.
Note that it can be called having Cc on the stack too from inside
CcInitializeCacheMap.
So, no reliable way of doing this.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
On 04/09/01, ““Maxim S. Shatskih” ” wrote:
> > Could anyone tell me please how can a File System Filter detect the moment
> > an application calls CreateFileMapping() on a file?
>
> AcquireFileForNtCreateSection fastIO callback.
> Note that it can be called having Cc on the stack too from inside
> CcInitializeCacheMap.
> So, no reliable way of doing this.
>
> Max
>
Well, really my question was quite incorrect 
I was wondering how could
I detect the moment the previously mapped section was unmapped and the
changes were being written to the file? Or how can I detect if there mapped
views of section during CLEANUP?
Thanx for the reply anyway
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> Well, really my question was quite incorrect I was wondering how could
I detect the moment the previously mapped section was unmapped and the
changes were being written to the file?
I don’t think it is possible at all except the CLOSE being called.
Or how can I detect if there mapped
views of section during CLEANUP?
No way. You will not be able to distinguish the user mapped view from the
cache section at CLEANUP. Both use the same
SectionObjectPointers->DataSectionObject thing.
Note that the cache section is NOT teared down at CLEANUP - it is just
released and put to some Cc’c internal list. This is the last reference to
the file object and possibly the FCB.
After some time (defined by Cc’s policies) will pass, the Cc will tear down
this unused cache section, thus dereferencing the file object and invoking
CLOSE, which will in turn destroy the file object and the FCB.
If the file was reopened during this time - CcInitializeCacheMap will re-use
this old cache section, taking it off the Cc’s unused list.
This “some time” can be hours. Cc uses this to optimize the
open-close-reopen case by keeping the cached data for a file object some
time after it was closed - if the memory load permits this.
So, the decision to send IRP_MJ_CLOSE is usually Cc’s responsibility. You
can force this by calling CcPurgeCacheSection from your cleanup code. I have
sent a working code sample (from the debugged code) here one day.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
Well, really my question was quite incorrect
I detect the moment the previously mapped section was unmapped and the
changes were being written to the file? Or how can I detect if there
mapped
views of section during CLEANUP?
Write a test application for mapping a file and flushing. Insert a break
point in ur Driver for each HOOK. After getting a control in ur driver check
that is ur File Only.
Try to figure out what exactly he is doing inside in above way.
Regards,
Satish K.S
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>So, return to my original question. It is unsafe to reference the
current process handle in IRP_MJ_CLOSE path, right? Looks like in some
Surely, IRP_MJ_CLOSE could be sent from the Cc’s internals by the Cc’s
worker thread which dereferences the stale cache maps.
It has NO connection to the process who originally opened the file.
Max
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Chendong,
I don’t believe the problem is the current process handle (since
NtCurrentProcess() evaluates to the constant value “-1”.) I suspect the
problem is the process token, which must be “gone” at the point you are
attempting to capture it (during process tear-down.)
In order to answer the original design question, though, we’d need to
understand better what you wanted to accomplish by grabbing the token.
If the goal is to know “who” is operating on the file, the ONLY time you can
do that safely is during IRP_MJ_CREATE. Why? Well, because security checks
are done when the handle is created and that is done during the inital
open/create sequence. So, after the handle is created there’s no longer any
NEED to operate in the correct security context (well, almost never.) SRV
(the CIFS file server) is notorious for this - impersonate during the
IRP_MJ_CREATE sequence but not during any subsequent call.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Chendong Shan [mailto:xxxxx@usa.net]
Sent: Tuesday, April 10, 2001 7:36 PM
To: File Systems Developers
Subject: [ntfsd] Re: [RE: Reference current process in the close path]
Tony,
Thank you for your quick reply.
The cases I observed were all happened during process termination (and
file close then). That’s why I suspected that in close path, it maybe
unsafe to reference current process handle.
And yes, the TokenHandle is in valid memory address. So it must be
ZwOpenProcessToken cause the access violation.
It is the second case (KMODE_EXCEPTION_NOT_HANDLED with the exception
0xC0000005).
Your note is correct. I guess we have to reconsider the algorithm
on CLOSE.
So, return to my original question. It is unsafe to reference the
current process handle in IRP_MJ_CLOSE path, right? Looks like in some
(very rare) situation, there maybe close file handle call at the end of
process dereference handler.
Chendong
Tony Mason wrote:
Chendong,
An access violation would indicate the address of the invalid memory
location. When this happens, can you observe anything interesting on the
stack? For example, are you in a process termination path or something
equally interesting?
I’m assuming you can confirm that TokenHandle is a valid memory location,
right?
And by “access violation” is it reported as a status code of 0xC0000005? Or
is it reported as a bugcheck (KMODE_EXCEPTION_NOT_HANDLED with the exception
being 0xC0000005?)
The last thing I would note is that you may have a fundamental design flaw
here, if you believe that IRP_MJ_CLOSE (and the process token) is going to
have anything to do with the process that opened and/or operated on the
file.
Regards,
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: Chendong Shan [mailto:xxxxx@usa.net]
Sent: Tuesday, April 10, 2001 6:45 PM
To: File Systems Developers
Subject: [ntfsd] Reference current process in the close path
Hi, All,
I send this message to NTDEV list this morning but didn’t see any reply.
I guess maybe it is better to post it here.
I have a FS filter driver in which I need to monitor the IRP_MJ_CLOSE.
When I decide that the file need further process, I have to get the user
SID. In order to do that, in some point I call ZwOpenProcessToken using
the follow code:
if( KeGetCurrentIrql() < DISPATCH_LEVEL)
{
Status=ZwOpenProcessToken(NtCurrentProcess(),TOKEN_READ,&TokenHandle);
…
}
In very rare situation, my driver got Access Violation inside
ZwOpenProcessToken. So my question is: is it safe to reference
the current process in file close path? If not, what’s the reason?
(process terminate before the close?) And how can I get the user
SID in close path?
Thanks a lot.
Chendong
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
—
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com