Even though i had set PreSTATUS_ACCESS_DENIED flag

hello, i’m making windows minifilter device driver. this driver purpose is for protecting files from delete, modification, ect…

my driver code referred to MS github repo for device driver

i’ve attached only PRE operation code because i can see that calling PRE operation when i had tried to remove files that protected by minifilter.
and actually my driver had worked well before, but someday, it doesn’t work… the reason? i really don’t know why…

CASE - trying to remove target.txt using windows CMD del command
env : windows 7 32bit

… pseudo code

     FLT_PREOP_CALLBACK_STATUS
     MyPreCallbackMethod (
         _Inout_ PFLT_CALLBACK_DATA Data,
         _In_ PCFLT_RELATED_OBJECTS FltObjects,
         _Outptr_result_maybenull_ PVOID *CompletionContext
         )
    
        .....
         if ( MyFunction_DoesExistProtectList("target.txt") )
         {
                dbgPrint("set STATUS_ACCESS_DENIED");
                Data->IoStatus.Status = STATUS_ACCESS_DENIED;
                Data->IoStatus.Information = 0;
    
                return FLT_PREOP_COMPLETE;
         }
         return FLT_PREOP_SUCCESS_NO_CALLBACK;
     }

i can see the log that dose said “set STATUS_ACCESS_DENIED” and checked my minifilter status using fltmc CMD command.
but i can still remove target.txt…

could you help me???

I’m not going to download code from github, I don’t have time to do a code review. I’ll note that your pseudo code won’t

  • delete files
  • handle relative opens
  • handle short names
  • handle open by ID or open by Object ID

But that isn’t your problem right now.
Have you attached a debugger and stepped through your callback? Did that tell you anything? Obviously you are only attaching to a test volume right now so the noise should be bearable.

@rod_widdowson said:
I’m not going to download code from github, I don’t have time to do a code review. I’ll note that your pseudo code won’t

  • delete files
  • handle relative opens
  • handle short names
  • handle open by ID or open by Object ID

But that isn’t your problem right now.
Have you attached a debugger and stepped through your callback? Did that tell you anything? Obviously you are only attaching to a test volume right now so the noise should be bearable.

Thank you for reply, but i’m so sorry… i can’t tell more detail code because this product under my company… not my own. so sorry…

but i have question about your reply,

i thought this code will work when i executed “del ” at CMD, and then IRP_MJ_SET_INFORMATION triggered and then reached my MyPreCallbackMethod that registered at minifilter registeration callback functions, so, in MyPreCallbackMethod, Data->IoStatus->Status as STATUS_ACCESS_DENIED run and i thought it makes access deny for “del ” command, my theory is right???
because i always did like that when i made driver that preventing access from user.

and i’m so sorry for my english… i don’t have much time to write this comment, some of reasons…

thank you for read my comments. have a nice day!

key_kim wrote:

i thought this code will work when i executed "del " at CMD, and then IRP_MJ_SET_INFORMATION
triggered and then reached my MyPreCallbackMethod that registered at minifilter registeration
callback functions, so, in MyPreCallbackMethod, Data->IoStatus->Status as STATUS_ACCESS_DENIED
run and i thought it makes access deny for "del " command, my theory is right???

In order to prevent file deletion from disk, you need to handle at
least two main scenarios:

  1. IRP_MJ_SET_INFORMATION + FileDispositionInformation(Ex).
  2. IRP_MJ_CREATE + FILE_DELETE_ON_CLOSE.

Also, keep in mind that preventing of file deleting does not protect
from erasing information by some other ways (low level access to
storage device, using of “wipe” utilities, etc).