Hi guys,
Do any FS filters / OS components depend on Flags, AllocationSize, FileSize, ValidDataLength fields of FSRTL_ADVANCED_FCB_HEADER being properly maintained? I use a shadow FS device approach to isolate access to certain files from certain applications, so I maintain my own FCB/CCB on shadow FOs opened on the shadow device. Due to the use case, no integration with memory and cache managers is required, so they are out of the picture. Properly maintaining those fields in my shadow FO is a hassle, so I wander if I can simply keep them zeroed without breaking other filters / OS components. Does anybody know?
TIA,
Vladimir
On 8/24/2010 12:28 PM, xxxxx@gmail.com wrote:
Hi guys,
Do any FS filters / OS components depend on Flags, AllocationSize, FileSize, ValidDataLength fields of FSRTL_ADVANCED_FCB_HEADER being properly maintained? I use a shadow FS device approach to isolate access to certain files from certain applications, so I maintain my own FCB/CCB on shadow FOs opened on the shadow device. Due to the use case, no integration with memory and cache managers is required, so they are out of the picture. Properly maintaining those fields in my shadow FO is a hassle, so I wander if I can simply keep them zeroed without breaking other filters / OS components. Does anybody know?
There is a flag value indicating it is an advanced header and system
components do peek into that structure. That said, if you’re not
integrating with CM and MM then you are probably OK setting the size
fields to zero but I’ve not tried it.
Are you seeing any specific problems?
Pete
TIA,
Vladimir
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
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Hi Peter,
Thanks for replying. No, I don’t see any problems (and I didn’t expect any problems), but I didn’t test on the whole variety of filters over there neither. So, before I fully commit to the design, I wanted to check with the community.
On 8/24/2010 12:59 PM, xxxxx@gmail.com wrote:
Hi Peter,
Thanks for replying. No, I don’t see any problems (and I didn’t expect any problems), but I didn’t test on the whole variety of filters over there neither. So, before I fully commit to the design, I wanted to check with the community.
One thing, I was specifically mentioning the OS. Whether or not other
filters, 3rd party filters, rely on this is an unknown. I can say that
other filters should not be peeking into the header but they do, all the
time. So if there are filters above you I wouldn’t count out the fact
that they are looking into the headers and performing actions based on
the sizes.
Pete
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
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
This was my exact concern 
However, given that this is a shadow file system device we’re talking about, I don’t expect many filters to attach to it (I don’t see Filter Manager attaching to my shadow device, so, probably the whole class of minifilters can be ruled out).
On 8/24/2010 2:52 PM, xxxxx@gmail.com wrote:
This was my exact concern However, given that this is a shadow file system device we’re talking about, I don’t expect many filters to attach to it (I don’t see Filter Manager attaching to my shadow device, so, probably the whole class of minifilters can be ruled out).
If you register as a file system, FM will attach to you. As well, legacy
filters will attach to you.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
> If you register as a file system, FM will attach to you. As well, legacy
filters will attach to you.
Except for the filters that refuse to filter anything that doesn’t have a
DriverName of FAT or NTFS (a major pain in some cases).
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Peter Scott” wrote in message
news:xxxxx@ntfsd…
> On 8/24/2010 2:52 PM, xxxxx@gmail.com wrote:
>> This was my exact concern However, given that this is a shadow file
>> system device we’re talking about, I don’t expect many filters to attach
>> to it (I don’t see Filter Manager attaching to my shadow device, so,
>> probably the whole class of minifilters can be ruled out).
>>
>
> If you register as a file system, FM will attach to you. As well, legacy
> filters will attach to you.
>
> Pete
>
> –
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> 866.263.9295
>
I don’t register as a file system. I have a minifilter that creates a shadow file system device for each volume it attaches. Then I reparse creates for certain files in context of certain processes to the shadow device, where I maintain two file objects: shadow FO (opened on and managed by the shadow device) and the backing FO FltCreated to back the shadow FO with file data. Then (for the most part) I just IoCallDriver(actual_fs_device_my_filter_is_attached) for majority of IRPs issued against my shadow FO (substituting FO/device in the next IRP stack location with the backing FO/device). This works like a charm, but raises question on how much maintenance I have to put on shadow FCB and FO itself in order not to break filters that may attach to my shadow (I knnow that some AVs, like Kaspersky, will attach to shadow devices). That’s where my question came from.
P.S. Again, this is not “general purpose” product, it’s targeting specific apps, where memory mapping support is not a requirement, so it releases me from the burden of MM/CM integration in my shadow FOs.
The problem is that if you don’t register as a file system it’s possible for
filters above to be bypassed for any operations on that file (you reparse
the create to a device object that they’re not filtering). Either this is or
isn’t a problem for you depending on your environment.
Generally filters don’t go poking into the size fields, but that’s not a
rule that you’ll find to be 100% followed. Interop is a *major* pain and a
moving target (hence PlugFest).
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntfsd…
> I don’t register as a file system. I have a minifilter that creates a
> shadow file system device for each volume it attaches. Then I reparse
> creates for certain files in context of certain processes to the shadow
> device, where I maintain two file objects: shadow FO (opened on and
> managed by the shadow device) and the backing FO FltCreated to back the
> shadow FO with file data. Then (for the most part) I just
> IoCallDriver(actual_fs_device_my_filter_is_attached) for majority of IRPs
> issued against my shadow FO (substituting FO/device in the next IRP stack
> location with the backing FO/device). This works like a charm, but raises
> question on how much maintenance I have to put on shadow FCB and FO itself
> in order not to break filters that may attach to my shadow (I knnow that
> some AVs, like Kaspersky, will attach to shadow devices). That’s where
> my question came from.
> P.S. Again, this is not “general purpose” product, it’s targeting specific
> apps, where memory mapping support is not a requirement, so it releases me
> from the burden of MM/CM integration in my shadow FOs.
>
I don’t think that the fact that some filters get bypassed when a file is accessed via my shadow device is going to create problems in my particular case, but this is a subject of further testing. I may be wrong, but I think that shadowing just FO, and fooling others to think that it has been opened by NTFS could be even more dangerous.
And of course I’m going to test it on plugfest