my Volume access control minifilter causes USB mass storage eject to fail

If your policy is for write access denied are you handling the queries on whether the volume is write protected and indicating it is read only? You cannot just blindly stop all writes to the volume, unless you have done this.

I am assuming that this is a system wide block of the writes.

1 Like

It is a per volume write or read policy.
And basically only applies block rules for removable devices.

If your policy is for write access denied are you handling the queries on whether the volume is write protected and indicating it is read only? You >cannot just blindly stop all writes to the volume, unless you have done this.
No I haven’t. So I need an advice on how to handle write protected queries here and after that I’m good to block write access as I am doing here?
Seems to me it is not ok to block all writes even after handling write protected

are you handling the queries on whether the volume is write protected and indicating it is read only?
I have seen other posts on this context here and on Microsoft forums a lot. I actually searched this thoroughly on the internet before I start coding.
I mean, Is this write-protected queries conversation valid in FS minifilter context? How can I intercept such query in a minifilter?
Isn’t that a disk(or maybe other) class filter driver you are talking about?

Well, that WOULD be the logical question. Why are you trying to apply a read-only constraint to a volume in a FS Minifilter, when the right place to do this is a volume filter.

Peter

Thanks for response Peter. The satisfying answer to why i chose FS minifilter would be lack of knowledge. About the volume filter you said, are we talking about a KMDF filter driver? And above what driver? And if I want to pot the read-only constraint on the whole disk it would be a KMDF above disk.sys. right?

Yes, a KMDF filter. Above the Volume Manager.

If you want to do this “for a whole disk”… (where there could be multiple partitions) you COULD do it above disk.sys — though, I’ve personally never tried that.

Peter

Btw, Let’s say i put a filter abow disk.sys and make a usb stick disk read-only. Since it is the physical disk abstraction level we are talking about. Can I then successfully execute the “safely remove hardware” process? On an above comment Don Brun sent he said: > You will need to allow access to the boot sector and volume header to deal with removal correctly. Maybe this means a disk filter would fail in safe removal too? But that is the whole disk removal! It probably won’t need access to a volume header. Specially when the disk itself declares it is read-only right from the start. May I ask for a bit of more clarification here?

Sorry to take so long to respond. I didn’t want to try to answer this from my iPad.

What you want to do is make the file system have to deal with the whole issue of the volume being read-only. When a volume is first mounted, the file system sends a (long and torturous) series of queries/IOCTLs to the underlying volume. One of those is to determine if the underlying media is write-enabled. The results of this query allow the file system to “do the right thing.”

The IOCTL the file system sends is IOCTL_DISK_IS_WRITABLE (see this in the FAT file system source code here). If the disk IS writable, the request is completed with success, if not the request is completed with STATUS_MEDIA_WRITE_PROTECTED (see the DISK class driver source code here).

Sooo… all you need to do is filter where you want, and when you see IOCTL_DISK_IS_WRITABLE complete the request with STATUS_MEDIA_WRITE_PROTECTED. And… bingo! The file system will treat the disk as being read only, and nothing else is your concern.

It really is simplicity itself.

Peter

Thanks for your consideration!
Guess I will jump into writing and building my first KMDF filter rather than taking your time with imaginary questions.
I will try to get to the point you said.

If you want a bare-bones place to start… you’re welcome to look here.

You’ll need to add a default Queue, and an EvtIoDeviceControl callback.

If you filter above the Volume or Disk classes, you’ll also need to figure out some way to know which INSTANCE of the class you’re instantiated over and (therefore) whether or not you want to fake it to be read-only. This is likely to be the hardest part of the project, really.

I hope that all helps,

Peter

I started ahead with building and testing toaster sample from Microsoft.
I would gladly look at the sample you pointed to. And enjoy playing with it!

The filter driver from toaster sample just got installed using the inf file.
So I am wondering if the talk about the need for an installer app in the “KMDF Filter Driver: 30-Minutes – Installation: Ah…Somewhat Longer” article is valid yet or it was an issue of the date the article was written?
In short if I change that CDfilter sample and build it, I would need and installer app or my filter will install using the inf itself?

You’re right to ask about that article… it’s almost 15 years old, and was written within a year of the formal release of KMDF.

The issue that article discusses has to do with getting the CO-INSTALLER on the target machine. This should no longer be an issue, because a reasonably useful version of KMDF has shipped in box, with every version of Windows since Windows 7. If you build your driver and target KMDF V1.9, which was released in-box with Windows 7, then your driver will be able to run without any issues on every version of Windows starting with Windows 7.

That means you CAN just use a “right click” INF that does something like:

[DefaultInstall.NT]
CopyFiles = @Filter.sys
Addreg    = Filter.AddReg

[DestinationDirs]
DefaultDestDir = 12

[Filter.AddReg]
HKLM, System\CurrentControlSet\Control\Class\{DEVICE-INTERFACE-GUID-TO-FILTER}, UpperFilters, 0x00010008, %DriverName%     

You can find the appropriate Device Interface GUID in “devguid.h” in the WDK. See the INF with our CDFilter project I pointed you to on GitHub.

Peter

Thanks alot Peter for the great help

My KMDF disk filter is ready. Runs well and a minor functionality of making USB devices write protected was implemented!
The Question is why so easy!!! I actually fell in love with KMDF.
Just wanted to inform that I made something out of it.
Thanks again for helping me out!
you’ll also need to figure out some way to know which INSTANCE of the class you’re instantiated over and (therefore) whether or not you want to fake it to be read-only. This is likely to be the hardest part of the project, really.

@“Peter_Viscarola_(OSR)” said:
If you filter above the Volume or Disk classes, you’ll also need to figure out some way to know which INSTANCE of the class you’re instantiated over and (therefore) whether or not you want to fake it to be read-only. This is likely to be the hardest part of the project, really.

Time to get a little more dirty

Glad to be able to help.

Peter

I mean, Is this write-protected queries conversation valid in FS minifilter context? How can I intercept such query in a minifilter?

Thanks again for helping me out!

I am not an expert in PnP but I’m pretty sure that you want to let everything go down.

You cannot just blindly stop all writes to the volume

You know you’ve just replied to a thread that’s a year old, right?

I dunno, but I suspect that the OP isn’t still worried about this issue :wink: