I am trying to make a program (GUI+filter driver) that ask the user
whether a particular file operation should be allowed.
Just like the way ZoneAlarm operates, but what I want to implement is to
block file operations instead of internet operations.
Since the driver’s dispatch routine is called in the client process’
context, I think it is possible to wait for the user to responsible in the
GUI while other process’ file activities remain normal, am I correct?
However, this requires the filter driver to actively tell the GUI to
prompt the user, how can this be implemented? Or I should set a timer in
the GUI program to poll for the device driver?
Thank you for answering in advance.
> Since the driver’s dispatch routine is called in the client process’
context, I think it is possible to wait for the user to responsible in the
GUI while other process’ file activities remain normal, am I correct?
A dangerous thing.
If you will block paging IO this way - then you can hang the UI very well due to deadlock.
I would recommend to inspect CreateFiles only, and not other operations.
Max
> A dangerous thing.
If you will block paging IO this way
- then you can hang the UI very well due to deadlock.
I would recommend to inspect CreateFiles only, and not other operations.
I am just a beginner in making device driver.
So I want to know the details about why blocking paging IO will hang the
UI due to deadlock.
Is paging IO refers to the IO about page swapping?
Since the UI may also be swapped out, blocking other process’ paging IO
will also block the UI?
If I change the UI to poll for the driver, see if a prompt to user should
be made, does it help?
Thank you in advance for your explanation.
> I am just a beginner in making device driver.
So I want to know the details about why blocking paging IO will hang the
UI due to deadlock.
Is paging IO refers to the IO about page swapping?
Yes, and also to reading the code pages of EXEs and DLLs. If you will block the page fault IO from Explorer or Shell32 or User32 -
then there are huge chances you will hang the UI.
Since the UI may also be swapped out, blocking other process’ paging IO
will also block the UI?
Something like.
Max
> Yes, and also to reading the code pages of EXEs and DLLs. If you will block
the page fault IO from Explorer or Shell32 or User32 -
then there are huge chances you will hang the UI.
Thank you for answer my questions.
If I only block IRP with MajorFunction == IRP_MJ_READ, avoid blocking
IRP_PAGING_IO and IRP_SYNCHRONOUS_PAGING_IO, and all system process like
Explorer, Shell32, User32, can the problem of possible deadlock be solved?
By the way, is blocking IRP with MajorFunction == IRP_MJ_READ and blocking
Fast IO Call of FastIoRead enough for blocking process from reading file’s
content?
Why not block the process form opening the file? If the user is not
allowed to read the file, then what is the purpose of allowing the user
to open the file?
You can also munge (change) the flags of the create call and not allow
the file to open with read or write access.
I think you can simplify your design a bit by keeping things simple.
Jamey Kirby
StorageCraft, inc.
xxxxx@storagecraft.com
www.storagecraft.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Sherman
Sent: Sunday, March 24, 2002 8:50 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Filter driver that ask the user whether a
particular file operation should be allowed.
Yes, and also to reading the code pages of EXEs and DLLs. If you will
block
the page fault IO from Explorer or Shell32 or User32 -
then there are huge chances you will hang the UI.
Thank you for answer my questions.
If I only block IRP with MajorFunction == IRP_MJ_READ, avoid blocking
IRP_PAGING_IO and IRP_SYNCHRONOUS_PAGING_IO, and all system process like
Explorer, Shell32, User32, can the problem of possible deadlock be
solved?
By the way, is blocking IRP with MajorFunction == IRP_MJ_READ and
blocking
Fast IO Call of FastIoRead enough for blocking process from reading
file’s
content?
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%
> Why not block the process form opening the file? If the user is not
allowed to read the file, then what is the purpose of allowing the user
to open the file?
You can also munge (change) the flags of the create call and not allow
the file to open with read or write access.
I think you can simplify your design a bit by keeping things simple.
Jamey Kirby
StorageCraft, inc.
xxxxx@storagecraft.com
www.storagecraft.com
Thank you for your idea.
Firstly, a similar question again, blocking the IRP of IRP_MJ_CREATE is
sufficient to block the process from opening the file?
Is it meant that if I block the process form opening the file, the problem
about deadlock won’t occur?
How to munge the flags of the create call and not allow the file to open
with read or write access? Is it meant changing something in
IoGetCurrentIrpStackLocation(Irp)->flags or
IoGetCurrentIrpStackLocation(Irp)->Parameters.Create
before passing the IRP to the lower device?
>> Firstly, a similar question again, blocking the IRP of IRP_MJ_CREATE
is sufficient to block the process from opening the file? <<
Yes.
> Is it meant that if I block the process form opening the file, the
problem about deadlock won’t occur? <<
Correct.
> IoGetCurrentIrpStackLocation(Irp)->Parameters.Create before passing
the IRP to the lower device? <<
Yes. There are access flags. If you set the flags in the filter to be
“read attributes” only, a process can only open and read attribute
information about the file. It can not read data, write data or execute
the file. The requests will fail with an access violation error code.
I think the best solution, if you want to deny all access to the file,
is to fail the create call with STATUS_ACCESS_DENISED.
Jamey
You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%