While I have no issue with denying these writes from luser mode (binary disk
editor on a mounted volume == file system corruption), there are very
legitimate reasons for (e.g) a volume filter driver to need to do sector
based writes. While you indicate that there is no bypass, that is clearly
not true…otherwise Ntfs would be read-only.
Can you explain where and how the check is made, so that developers of
legitimate kernel mode software can generate their Irps in a way that will
allow them to get their job done?
If the check is in the file systems, then the answer for the OP is to not
open the volume through the FS–instead use the device object pointer he
already has in his filter.
If the check is somewhere in the storage stack, then there is some way to
format a request so that it looks like it came from the file system and will
be allowed.
Thanks,
- Dan.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jeff Goldner
Sent: Friday, January 26, 2007 10:18 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RE:*** Vista RTM *** Writing to raw disk sectors
(Unsigned Mail)
This is by design in Vista. Passthrough/raw writes within a mounted
partition will be failed. This is part of the mitigation of rootkits. There
is no bypass.
-----Original Message-----
From: Steven Bytnar [mailto:xxxxx@stg.com]
Sent: Friday, January 26, 2007 2:59 PM
Subject: RE:*** Vista RTM *** Writing to raw disk sectors (Unsigned Mail)
Hi,
I saw that no one answered Else Kluger’s request about IRP_MJ_WRITE from a
kernel mode storage filter driver below the file system.
http://www.osronline.com/showThread.cfm?link=101716
I have a driver of that form… a storage filter driver that intercepts disk
operations. I can say for sure that Vista RTM allows IRP_MJ_READ to any part
of the disk for my filter driver when I feed the requests to my lower
device. But, I keep getting STATUS_ACCESS_DENIED (0xC0000022) for any
IRP_MJ_WRITE request that falls within a mounted partition. This method
works fine under XP, 2K and NT 4, but not Vista RTM. Has anyone found a
solution or workaround that doesn’t involve unmounting the partition? Has
anyone filed a bug with Microsoft about this yet (care to share your bug #
for reference)?
The IRP_MJ_WRITE occurs on behalf of an application IOCTL. The application
is actually a service running as SYSTEM. The disk access permissions for C:\
show that the write request should succeed. SYSTEM has “All Access”. I tried
modifying the physical disk object’s “Security Attributes” with OSR’s
DeviceTree app to allow Everyone “All Access”, but the settings are ignored
and aren’t preserved… it doesn’t work around the problem.
Is there a policy setting that I can change in the registry
or is this new functionality hard coded into PartMgr.sys? PartMgr.sys is the
only driver that’s between me and the disk and I think it’s the one
generating the 0xC0000022 error.
I guess as a secondary question… how would I get an instance of the
PDEVICE_OBJECT that belongs to the lower device of the lower device that I’m
attached to? Could I workaround this by sending IRPs directly to the
Disk.sys device instead of having them go through PartMgr.sys?
Thank you,
–Steve
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer