I want to cancel operations in the Preoperation callback routine a.k.a. not let whatever it wants to do read/write/etc happen. According to this link:
http://msdn.microsoft.com/en-us/library/ff549831(v=vs.85).aspx
"A minifilter driver can change the I/O status for an operation when completing the operation in its preoperation callback or failing the operation in its postoperation callback (such as changing a STATUS_SUCCESS to an error status). It is not necessary to call FltSetCallbackDataDirty in this case. "
So if I set the Data->IoStatus.Status = STATUS_CANCELLED; will this actually cancel the operation or do I have to do something different because in the Postoperation callback I am still getting STATUS_SUCCES as the status result and the operations are still being completed?
You need to return FLT_PREOP_COMPLETE from the completion routine.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@yahoo.com” wrote in message
news:xxxxx@ntfsd:
> I want to cancel operations in the Preoperation callback routine a.k.a. not let whatever it wants to do read/write/etc happen. According to this link:
>
> http://msdn.microsoft.com/en-us/library/ff549831(v=vs.85).aspx
>
> "A minifilter driver can change the I/O status for an operation when completing the operation in its preoperation callback or failing the operation in its postoperation callback (such as changing a STATUS_SUCCESS to an error status). It is not necessary to call FltSetCallbackDataDirty in this case. "
>
> So if I set the Data->IoStatus.Status = STATUS_CANCELLED; will this actually cancel the operation or do I have to do something different because in the Postoperation callback I am still getting STATUS_SUCCES as the status result and the operations are still being completed?
Did you returned FLT_PREOP_COMPLETE from pre-op? It works fine for
pre-create and status like STATUS_ACCESS_DENIED.
I’m not sure about pre-write, as there might be some special cases, like
handling paging-io.
On 2011-08-05 16:26, xxxxx@yahoo.com wrote:
I want to cancel operations in the Preoperation callback routine a.k.a. not let whatever it wants to do read/write/etc happen. According to this link:
http://msdn.microsoft.com/en-us/library/ff549831(v=vs.85).aspx
“A minifilter driver can change the I/O status for an operation when completing the operation in its preoperation callback or failing the operation in its postoperation callback (such as changing a STATUS_SUCCESS to an error status). It is not necessary to call FltSetCallbackDataDirty in this case.”
So if I set the Data->IoStatus.Status = STATUS_CANCELLED; will this actually cancel the operation or do I have to do something different because in the Postoperation callback I am still getting STATUS_SUCCES as the status result and the operations are still being completed?
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars 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
–
Best regards,
Krystian Bigaj
Ahh that makes sense I was returning FLT_PREOP_SUCCESS_WITH_CALLBACK thanks for the help.
Normally I do something like this:
Data->IoStatus.Status = STATUS_ACCESS_DENIED;
Data->IoStatus.Information = 0;
return FLT_PREOP_COMPLETE;
This allows you fail any request, but (to quote my favorite PC game) you
might need to prepare for unforeseen consequences for failing some requests.
Also, you should be mindful of the status you chose return. STATUS_CANCELLED
is generally used to indicate that the IRP has been cancelled by the issuer
(IO manager) and might not be the right one for your scenario (which you
haven’t described at all). Just search for STATUS_CANCELLED and you’ll find
posts by people describing how they need to do special processing when
STATUS_CANCELLED is returned.
Thanks,
Alex.
Thanks Alex I did end up changing it to STATUS_ACCESS_DENIED. Basically what im trying to do is block a user from accessing something. I do this by allowing the user to specify the path and deny or allow. So what I just tested was C:.…\opera.exe with deny and when I try to open opera.exe Microsoft pops up a dialog box that says “Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.” I also tried opening it as administrator and the box came up. So I believe that changing the status to STATUS_ACCESS_DENIED is having the affect I want. Do you think a user could somehow get around this and still open something that was denied access thus breaking this theory?
Generally the preferred method if you want to block all access to a file is
to fail the request when processing IRP_MJ_CREATE.
“Do you think a user could somehow get around this and still open something
that was denied access thus breaking this theory?” - Well, the current
thinking is that you can’t prevent an administrator from doing whatever they
want. They could uninstall you filter driver or install one of their own
that bypasses yours completely and talks directly to NTFS or even dismount
the disk, start a linux VM and attach the dismounted disk as a disk to that
VM and use one of the linux NTFS implementations to access it. If we’re
talking about regular users with properly set access rights then this
approach should be fine (as far as I know). At least, the approach of
blocking IRP_MJ_CREATE; from your original post I was left with the
impression that you were allowing IRP_MJ_CREATE and then blocked IRP_MJ_READ
and others and unless you provide a full list of the operations you are
blocking it’s hard to tell whether it’s a complete set or not… Still my
advice would be to block IRP_MJ_CREATE for that file.
Security is a complicated problem and unless you exactly specify your design
and your constraints (are you trying to prevent files from being executed or
do you want to prevent their contents from being read or what? ) it’s
impossible to tell whether a solution is really secure. And even then it’s
hard…
Thanks,
Alex.