hi all…!!
i m average in File system Driver development… i m trying to develop a file system Auditing application where i need to log all activities regarding to the file system. to meet the various compliance i have to log all file system related activities which are unsuccessful also mean i have to log create requests which return STATUS_ACCESS_DENIED.
i have transferred my whole post-create code to a function using… FltDoComplitionProcessWhenSafe() function. now if i got Status of the file operation then i requested the Filename with using FltGetFileNameInformation () then i send the data to usermode application.
now problem is that if i m trying to access a file of which i have not any access permission(i change the file permission through security tab of file properties) then if i D-click on the file i got access denied in explorer but in driver i am able to see the status of operation and determine successfully that the reply of this operation is ACCESS_DENIED but when i use FltGetFileNameInformation() to get the full path of the file which was accessed i got the STATUS_FLT_INVALID_NAME_REQUEST.
i am using FltGetFileNameInformation() function whith these flags FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT.
so now i m able to log that there is a access denied condition meet but file path is not available. Rest of the ALLOW operations are successfully logged.
please suggest me something…you all are mentally giant here…
thanks in advance…
Hello Harish,
There a couple of things to look at.
First, there is no need to call FltDoCompletionProcessingWhenSafe in postCreate because FltMgr synchronizes all create operations so the postCreate callback will be called in the context of the original thread, which is at PASSIVE_LEVEL. In this case FltDoCompletionProcessingWhenSafe simply calls your function in line. FltDoCompletionProcessingWhenSafe is meant to be called for post callbacks that can be called at DISPATCH_LEVEL.
Second, FltGetFileNameInformation can return STATUS_FLT_INVALID_NAME_REQUEST for a lot of reasons, but in this particular case, based on your description, it’s probably because FltGetFileNameInformation cannot get the name in the postCreate callback if the CREATE failed. The reason for this is that FltGetFileNameInformation attempts to build the name by using FileObject->FileName if the file has not yet been opened (otherwise it queries the file system). However, in the case of a failed CREATE FileObject->FileName is not guaranteed to be valid (the file system can and does change the name in some error cases). A pretty common case to think about is the case of STATUS_REPARSE, where FileObject->FileName points to the new file to open.
I would suggest that if you want to log failed CREATEs you should move the name query in the preCreate callback. This is generally a performance hit and this approach should not be used by minifilters that don’t care about files that can’t be opened (like anti-virus minifilters, encryption etc.), but it is the only option for filters that need to intercept a create before it reaches the file system or that need to log even failed CREATEs.
Regards,
Alex.
This posting is provided “AS IS” with no warranties, and confers no rights.
but afaik PreCreate() can be called for a invalid file name also…
…but afaik PreCreate() can be called for a invalid file name also…
So what, create a completion context put the name in that and than use that in post create if your condition satisfied else free that.
your post create routine will become like this
if( status == access_denied or status is success )
{
fetch name from completion context
log it
}
free completion context
Thanks,
Aditya
but in precreate() path it is showing the same behavior. FltGetFileNameInformation is returning STATUS_FLT_INVALID_NAME_REQUEST even in the precreate path.
I have cross check this behavior with CONTEXT sample comes with IFS kit. even that sample is showing the same. FltGetFileNameInformation is returning STATUS_FLT_INVALID_NAME_REQUEST
i am screwed now cause these are very old work of mine and that time they were tested and working properly but now what happen to them. i have 5 virtual machines and every body is showing the same behavior. i m not sure is that any virus or rootkit kind of somthing.
i find one tread & MSDN also give some idea of regarding the process of TopLevelIRP. if it is NULL then FltGetFileNameInformation can return STATUS_FLT_INVALID_NAME_REQUEST.
i m stuck now. MiniFilter samples of IFS kit are also broken by this strange thing.
hope anyone of u people encounter the same behavior and he can give me some hint.
thank you all for Your previous responses…
calling FltGetFileNameInformation in preoperation is not a good idea at all as msdn suggest.
If FltGetFileNameInformation is called in the preoperation callback routine for a create operation to retrieve the opened name, FltGetFileNameInformation succeeds even if the path to the file being opened does not exist on the volume. If FltGetFileNameInformation is called in the preoperation callback routine for a create operation to retrieve the normalized name, FltGetFileNameInformation succeeds even if the final component of the path to the file being opened does not exist on the volume.
get it from fileobject->filename field and save it.
>i am screwed now cause these are very old work of mine and that time they were tested and working properly but now what happen to them. i have 5 virtual machines and every body is showing the same behavior.
Surprised, I guess some one from MS can tell you why they are not working now if you can provide the exact test environment where they worked for you.
>i m not sure is that any virus or rootkit kind of somthing.
Shouldn’t be, they only bother about their on disk files or this is what I found.
Thanks
Aditya
have a look on this thread and search for posts from for Mr. Ladisalv’s.
http://www.osronline.com/showThread.cfm?link=72139
A search on NTFSD will probably lead to some good approach. As suggested, search first.
Thanks
Aditya
typo*: its Ladislav Zezula
My BAD.