[Filter] Cancel PreOperation but deliver OK

Dear colleagues,

for my bachelor’s thesis i decided to write a filesystem filter driver to lock write access to certain USB devices. I am new to driver development, but not to low level development.

My work is based on the familiar minispy skeleton -> i block the IRP_MJ_CREATE operation like this:

BOOLEAN writeOperation = ((desiredAccess & (FILE_WRITE_DATA | FILE_WRITE_ATTRIBUTES | FILE_WRITE_EA | FILE_APPEND_DATA | DELETE | WRITE_DAC | WRITE_OWNER | FILE_ADD_FILE | FILE_ADD_SUBDIRECTORY)) ||
(Data->Iopb->Parameters.Create.Options & FILE_DELETE_ON_CLOSE));

if (writeOperation) {
Data->IoStatus.Status = STATUS_ACCESS_DENIED;
Data->IoStatus.Information = 0;
DbgPrint(“IRP Major: %u \n”, Data->Iopb->MajorFunction);
DbgPrint(“IRP Minor: %u \n”, Data->Iopb->MinorFunction);
return FLT_PREOP_COMPLETE;
}

I furthermore check createDispositon and blocking seems to work fine. All write operations fail with their corresponding error messages.
Thanks to the colleague who pointed out what to block in this thread: http://www.osronline.com/showThread.cfm?link=62996

Now, i want to have the same functionality, but instead of delivering STATUS_ACCESS_DENIED, i want to deliver “everything went ok” to the OS.
I have tried several things like setting Data->IoStatus.Information = 0; and setting Data->IoStatus.Status to STATUS_SUCCESS, but my driver crashes fatally.

Is there any possibility to achieve said behavior or do you think the effort will go beyond the scope of my abilites respectively the scope of a bachelors thesis?

Best regards and thanks,
Chris

If STATUS_SUCCESS is returned for IRP_MJ_CREATE the related file object must be initialized by a filter or file system driver( i.e. FsContext and SectionObjectPointer are being initialized in case of a file system). Then all subsequent requests for a file object must be processed ( at least IRP_MJ_CLEANUP and IRP_MJ_CLOSE to cleanup allocated resources ).

You got the point.

If you go into the SecurityContext structure and strip the offending bits
from RemainingDesiredAccess and PreviouslyGrantedAccess fields, the
operation will succeed but the application will not be able to write using
the returned handle. I’m not sure if this is good enough for your purposes,
but it’s likely to be vastly simpler than any other path you might go down.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

If STATUS_SUCCESS is returned for IRP_MJ_CREATE the related file object must
be initialized by a filter or file system driver( i.e. FsContext and
SectionObjectPointer are being initialized in case of a file system). Then
all subsequent requests for a file object must be processed ( at least
IRP_MJ_CLEANUP and IRP_MJ_CLOSE to cleanup allocated resources ).

You got the point.

@Scott: This is definitely worth a try, i will give it a shot!
Thank you both for your informations!

Another question came to my mind:
The current filter driver can only hook on volumes (at least in Fltmc.exe it looks that way). Which kind of filter would i need to write-protect a whole drive (eg \PHYSICALDRIVE3)?