Hello.
I am developing a mini filter and one of its features is to allow applications to set their current working directory to a path that does not exist. For instance, I’d like to do from the command line a “cd C:\foo\bar”, where directory “foo” exists but “bar” does not exist.
I suspect that I have to intercept the IRP_MJ_CREATE operation in the pre- path, correctly initialize an FCB, possibly update the FO, and finally complete the operation before it reaches the actual file system.
Right?
I’ve tried to apply this theory but without success. If I set the FsContext to my FCB I get BSOD somewhere within NTFS, which is strange since (I think) I don’t forward this request to the file system. If I don’t initialize at all an FCB then I get a “parameter incorrect” error.
(1) Is there something wrong in my theory?
(2) Is what I’m trying to do feasible?
(3) Is there an alternative approach?
Thank you for your attention.
On 8/24/2010 6:48 AM, xxxxx@bsc.es wrote:
Hello.
I am developing a mini filter and one of its features is to allow applications to set their current working directory to a path that does not exist. For instance, I’d like to do from the command line a “cd C:\foo\bar”, where directory “foo” exists but “bar” does not exist.
I suspect that I have to intercept the IRP_MJ_CREATE operation in the pre- path, correctly initialize an FCB, possibly update the FO, and finally complete the operation before it reaches the actual file system.
Right?
In short, you need to virtualize these entries. To do this you need to
implement a file system to handle all access to these non-existent
nodes. If you are going to handle creation of files and directories in
these virtualized nodes, things will get even more complicated.
To begin, look through the FAT source code, it has everything you need
to do to virtualize these entries.
As an alternative, you could have a pseudo directory, say c:\redirect
which does exist. Then reparse the entries you want to virtualize to
this real location. Then to protect file and directory creation, filter
accesses for creates to this directory, or not.
Good luck, this is a lot of work. I’ve done this many times and plan on
several months to get the first method ‘working’ and many more to get it
right.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
I'd completely concur with what Pete says, but remember his time estimates
are for someone whose done this many times....
You may also want to check out
The NT Insider:Getting Away From It All: The Isolation Driver (Part I) and its follow on articles
(when they appear).
Rod
Rod Widdowson
Consulting Partner
Steading System Software LLP
+44 1368 850217 +1 508 915 4790
"Peter Scott" wrote in message
news:xxxxx@ntfsd...
> On 8/24/2010 6:48 AM, xxxxx@bsc.es wrote:
>> Hello.
>>
>> I am developing a mini filter and one of its features is to allow
>> applications to set their current working directory to a path that does
>> not exist. For instance, I'd like to do from the command line a "cd
>> C:\foo\bar", where directory "foo" exists but "bar" does not exist.
>>
>> I suspect that I have to intercept the IRP_MJ_CREATE operation in the
>> pre- path, correctly initialize an FCB, possibly update the FO, and
>> finally complete the operation before it reaches the actual file system.
>>
>> Right?
>>
>
> In short, you need to virtualize these entries. To do this you need to
> implement a file system to handle all access to these non-existent nodes.
> If you are going to handle creation of files and directories in these
> virtualized nodes, things will get even more complicated.
>
> To begin, look through the FAT source code, it has everything you need to
> do to virtualize these entries.
>
> As an alternative, you could have a pseudo directory, say c:\redirect
> which does exist. Then reparse the entries you want to virtualize to this
> real location. Then to protect file and directory creation, filter
> accesses for creates to this directory, or not.
>
> Good luck, this is a lot of work. I've done this many times and plan on
> several months to get the first method 'working' and many more to get it
> right.
>
> Pete
>
> --
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> 866.263.9295
>
> I suspect that I have to intercept the IRP_MJ_CREATE operation in the pre- path, correctly initialize
I don’t think that minifilter is enough for such things.
You will need to write the full layered FSD probably.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thank you for your replies.
On 24/08/2010 18:54, Rod Widdowson wrote:
I’d completely concur with what Pete says, but remember his time
estimates are for someone whose done this many times…
You may also want to check out
http://www.osronline.com/article.cfm?article=560 and its follow on
articles (when they appear).
Rod
Rod Widdowson
Consulting Partner
Steading System Software LLP
+44 1368 850217 +1 508 915 4790
“Peter Scott” wrote in message
> news:xxxxx@ntfsd…
>> On 8/24/2010 6:48 AM, xxxxx@bsc.es wrote:
>>> Hello.
>>>
>>> I am developing a mini filter and one of its features is to allow
>>> applications to set their current working directory to a path that
>>> does not exist. For instance, I’d like to do from the command line a
>>> “cd C:\foo\bar”, where directory “foo” exists but “bar” does not exist.
>>>
>>> I suspect that I have to intercept the IRP_MJ_CREATE operation in the
>>> pre- path, correctly initialize an FCB, possibly update the FO, and
>>> finally complete the operation before it reaches the actual file system.
>>>
>>> Right?
>>>
>>
>> In short, you need to virtualize these entries. To do this you need to
>> implement a file system to handle all access to these non-existent
>> nodes. If you are going to handle creation of files and directories in
>> these virtualized nodes, things will get even more complicated.
I only need to handle setting the current working directory to a
non-existent directory. Creating files into a non-existing directory
will be addressed with pathname reparsing.
>>
>> To begin, look through the FAT source code, it has everything you need
>> to do to virtualize these entries.
>>
>> As an alternative, you could have a pseudo directory, say c:\redirect
>> which does exist. Then reparse the entries you want to virtualize to
>> this real location. Then to protect file and directory creation,
>> filter accesses for creates to this directory, or not.
I am aware of this solution. However, I’d like to spend some time trying
to do it this way.
>>
>> Good luck, this is a lot of work. I’ve done this many times and plan
>> on several months to get the first method ‘working’ and many more to
>> get it right.
This is something my boss has to worry about!
>>
>> Pete
>>
>> –
>> Kernel Drivers
>> Windows File System and Device Driver Consulting
>> www.KernelDrivers.com
>> 866.263.9295
>>
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
What I have to do is very similar to this:
http://www.osronline.com/showThread.cfm?link=133867 but without the
database stuff.
I try to complete the operation in the pre- path this way:
…
Data->IoStatus.Information = FILE_OPENED;
Data->IoStatus.Status = STATUS_SUCCESS;
return FLT_PREOP_COMPLETE;
…
but I get a “The parameter is incorrect” error.
In trying to find out which parameter is incorrect, I assumed it was
because the FCB does not exist. Allocating, initializing, and setting an
FCB leads to a system crash since NTFS somehow accesses this FO,
pretty much like it’s stated here:
http://www.osronline.com/showthread.cfm?link=153641.
Based on this result, I choose to replace the original FO (the one
stored in Data->Iopb->TargetFileObject) by creating a new FO, memcpy the
contents of original FO to the new FO, and finally set
Data->Iopb->TargetFileObject to point to the new FO (and also call
FltSetCallbackDataDirty). I still get the “The parameter is incorrect”
error.
If the non-existent file actually exists, then in the post- path I can
replace the original FO with a copy of it (exactly as described in the
previous paragraph), and finally get a successful result.
My assumption is that I am not initializing some other structure, apart
from the FO. Before diving into the fastfat source code, do you think
I’m missing something obvious?
Thank you.
–
Thanos Makatos
Junior Engineer
Storage Systems Research Group - Computer Science Department
Barcelona Supercomputing Center - Centro Nacional de Supercomputación
http://www.bsc.es/StorageSystems
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer.htm
I managed to get past the “The parameter is incorrect.” error. The problem was that during the directory listing operation I didn’t properly initialize the “ShortName” and “ShortNameLength” fields in the “FileIdBothDirectoryInformation” information class. It seems cmd.exe does use these fields.
I complete IRP_MJ_CREATEs in the pre-create path as follows:
Data->IoStatus.Information = FILE_OPENED;
Data->IoStatus.Status = STATUS_SUCCESS;
return FLT_PREOP_COMPLETE;
However, if a later IRP (e.g. IRP_MJ_DIRECTORY_CONTROL) uses this FO, I can’t attach a stream handle context to it, I get a STATUS_NOT_SUPPORTED error. Is this due to the total absence of a valid FCB (FsContext is NULL)? Is it because there’s something else I haven’t taken care of?
From MSDN: “To support file contexts (if applicable), stream contexts, and file object (stream handle) contexts, a file system must use the FSRTL_ADVANCED_FCB_HEADER structure.”
So I do have to keep a valid FCB. The problem is that IRPs on FOs whose FCB is constructed by me somehow reach NTFS, which crashes since it doesn’t understand the FCB. I have implemented name provider callbacks. Any idea why NTFS gets to see my FOs?
Are you initializing the VPB and section object pointers in file objects
from IRP_MJ_CREATE?
Jeff
On Mon, Sep 13, 2010 at 7:36 AM, wrote:
> From MSDN: “To support file contexts (if applicable), stream contexts, and
> file object (stream handle) contexts, a file system must use the
> FSRTL_ADVANCED_FCB_HEADER structure.”
>
> So I do have to keep a valid FCB. The problem is that IRPs on FOs whose FCB
> is constructed by me somehow reach NTFS, which crashes since it doesn’t
> understand the FCB. I have implemented name provider callbacks. Any idea why
> NTFS gets to see my FOs?
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
No I don’t. The FO is a virtual directory. Do I have to initialize them?
On Mon, Sep 13, 2010 at 8:41 AM, wrote:
> No I don’t. The FO is a virtual directory. Do I have to initialize them?
>
Definitely–that’s how requests are routed to the target filesystem, which
yours is since it handled the IRP_MJ_CREATE for them.
Since your filesystem never gets explicitly mounted, I think you should be
able to get by with associating a VPB you care simply for the purposes of
showing which device to send IRPs to.
Just curious, what kind of operations are you planning to support for these
virtual files?
Jeff
Thank you for your reply Jeff.
The VPB and SOB pointers are always NULL, how can the I/O manager ultimately route this IRP down to the FS? Shouldn’t the I/O manager crash?
Here’s a stack trace:
900536c4 8e0cdef1 900537b4 8b50e858 90053704 Ntfs!NtfsDecodeFileObject+0x39
9005373c 8e0d3a4d 900537b4 8b687e28 1e027e60 Ntfs!NtfsCommonQueryInformation+0x56
900537a0 8e0e1d53 900537b4 8b687e28 00000001 Ntfs!NtfsFsdDispatchSwitch+0x17b
900538d4 828884bc 8c66b020 8b687e28 8b687e28 Ntfs!NtfsFsdDispatchWait+0x1c
900538ec 8df3a20c 8c275550 8b687e28 00000000 nt!IofCallDriver+0x63
90053910 8df3a3cb 90053930 8c275550 00000000 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2aa
90053948 828884bc 8c275550 8b687e28 8c275550 fltmgr!FltpDispatch+0xc5
90053960 82ac9f68 90053be4 8b50e858 8b582eb0 nt!IofCallDriver+0x63
90053990 82a62bb3 8b50e858 00000004 00000028 nt!IopQueryXxxInformation+0x134
900539b4 82a8cc23 8b50e858 00000004 00000028 nt!IoQueryFileInformation+0x1d
90053aa0 82a6d1d7 8c424030 c546b6e0 8b580008 nt!IopParseDevice+0x14c5
90053b1c 82a9324d 00000000 90053b70 00000040 nt!ObpLookupObjectName+0x4fa
90053b78 82aaec6a 0018e174 8b46b6e0 8b50e801 nt!ObOpenObjectByName+0x159
90053d24 8288f42a 0018e174 0018e14c 0018e194 nt!NtQueryAttributesFile+0x121
90053d24 773664f4 0018e174 0018e14c 0018e194 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
0018e194 00000000 00000000 00000000 00000000 0x773664f4
Why do I have to associate a VPB since completing an IRP means that it won’t be sent downwards in the I/O stack?
Just to clarify things, I only want to virtualize a directory, not the files inside a virtualized directory.
I will try to restate my problem in order to make it more straightforward.
I complete an IRP_MJ_CREATE in the pre-op. path and add an FCB to the
FO. Immediately after NTFS gets called (see the stack trace in previous
post). This contradicts MSDN:
“FLT_PREOP_COMPLETE
The minifilter driver is completing the I/O operation. The filter
manager does not send the I/O operation to any minifilter drivers below
the caller in the driver stack or to the file system. In this case, the
filter manager only calls the post-operation callback routines of the
minifilter drivers above the caller in the driver stack.”
On 13/09/2010 17:51, xxxxx@bsc.es wrote:
Just to clarify things, I only want to virtualize a directory, not the files inside a virtualized directory.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Thanos Makatos
Junior Engineer
Storage Systems Research Group - Computer Science Department
Barcelona Supercomputing Center - Centro Nacional de Supercomputación
http://www.bsc.es/StorageSystems
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer.htm
On Wed, Sep 15, 2010 at 3:26 PM, Thanos Makatos wrote:
> I complete an IRP_MJ_CREATE in the pre-op. path and add an FCB to the FO.
How do you complete IRP_MJ_CREATE?
> Immediately after NTFS gets called (see the stack trace in previous post).
WHEN does NTFS get called? If you complete IRP_MJ_CREATE in
pre-create, NTFS get’s called only because you did something that
generated a call into a filesystem (which is obviously what you want
since you need access to the real volume in order to provide a
namespace that depends on the real underlying namespace).
> “FLT_PREOP_COMPLETE
> The minifilter driver is completing the I/O operation. The filter manager
> does not send the I/O operation to any minifilter drivers below the caller
> in the driver stack or to the file system. In this case, the filter manager
> only calls the post-operation callback routines of the minifilter drivers
> above the caller in the driver stack.”
How did you determine the cause of the call into NTFS at create time?
Your approach seems complicated, why not just change target in your
minifilter and let the FS do all the processing, instead of doing the
processing yourself?
–
Aram Hăvărneanu
Did you filter the query information file call ?
Basically, once you complete a CREATE, you MUST create ALL operations at
your level for that FO. Looking at the stack, it looks like
IRP_MJ_QUERY_INFORMATION is not handled by your filter.
Thanks,
Alex.
It turns out that I didn’t properly intercept the QUERY_INFORMATION
operation due to a path name coming in a non-expected form… It works
fine now. Thank you all for your interest and sorry for wasting your time…
On 15/09/2010 17:30, Alex Carp wrote:
Did you filter the query information file call ?
Basically, once you complete a CREATE, you MUST create ALL operations at
your level for that FO. Looking at the stack, it looks like
IRP_MJ_QUERY_INFORMATION is not handled by your filter.
Thanks,
Alex.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Thanos Makatos
Junior Engineer
Storage Systems Research Group - Computer Science Department
Barcelona Supercomputing Center - Centro Nacional de Supercomputación
http://www.bsc.es/StorageSystems
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer.htm