For the kind of i/o’s that file system filters normally see, the user
buffer is passed untouched down to the file system.
I/O probes the buffer for the desired access - write in case of
IRP_MJ_READ, and read in case of IRP_MJ_WRITE.
This is by no means sufficient when you are actually accessing the
buffer. This does NOT mean the filter can automatically assume the
buffer has read or write access as appropriate - or that it’s even
valid. The reason being that the user can actually change the protection
on the buffer - or even invalidate it from another thread
asynchronously. If you intend to access the user buffer directly, you
will either need to probe & lock it down wrapped by an exception handler
first, after which you can safely access the contents, or you would need
to wrap the access to the buffer in an exception handler to guard
against malicious users.
This applies both for read and write and all other operations (such as
METHOD_NEITHER IOCTLs or FSCTLs) where i/o doesn’t capture the buffer
itself.
Ravi
This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use
-----Original Message-----
From: Mike Malgin [mailto:xxxxx@yahoo.com]
Sent: Wednesday, January 16, 2002 1:35 AM
To: File Systems Developers
Subject: [ntfsd] RE: Altering User Data During IRP_MJ_WRITE
Hi,
I wondered if there is any way to check(e.g, in the
IRP)if a modification is allowed on a certain IRP
buffer ?
Another thing, if this request was IRP_MJ_READ
would it be safe to modify the IRP buffer ?
Obviously, the IRP buffer is going to be modified by
the lower driver so it cannot be on read only memory.
Is there something that I miss in my assumption ?
Thanks,
-Mike
— Pavel Hrdina wrote:
> Answer to : Why must it be restored?
>
> Because there may be some additional filter above
> you and may
> count on the buffer which it sent to you (as you may
> do with the new
> buffer you are sending down), so you should be as
> most transparent
> as you can - and hope those below you will be too.
>
> Answer to : Hmm, I thought the buffer allows write
> and not read access, in
> general, in the READ case?
>
> What do you mean exactly? Maybe you’re trying to say
> that the read
> operation ahould not try to read anything from the
> buffer…
> Yes, I agree with you, but the ProbeForWrite routine
> tries to read and
> then write what it has read. Thus I think that you
> can also read, but
> do not count on the content. Is it right?
>
> Paul
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Dejan Maksimovic
> Sent: Tuesday, January 15, 2002 11:00 PM
> To: File Systems Developers
> Subject: [ntfsd] RE: Altering User Data During
> IRP_MJ_WRITE
>
>
> > Never modify the buffer passed in for write,
> because you have no
> > permission to do so! The buffer can be
> concurrently used by someone
> > else! Moreover you can run into some troubles like
> in your case,
> > because the buffer can be in read only memory.
>
> And, the worst thing is that the user counts on
> the buffer NOT to be
> changed, as is expected.
>
> > So, you have to allocate your own buffer,
> transform the data to it and
> > pass it to the next lower level component (change
> it in the Irp, but
> > you have to restore the original buffer on the way
> out!)
>
> Why must it be restored?
>
> > But this is not the case for read operation,
> because it has the right
> > (from its definition) to alter the buffer untill
> the request is
> > completed.
>
> Hmm, I thought the buffer allows write and not
> read access, in
> general, in the READ case?
>
> –
> Kind regards, Dejan M. www.alfasp.com
> E-mail: xxxxx@alfasp.com ICQ#: 56570367
> Alfa File Monitor - File monitoring library for
> Win32 developers.
> Alfa File Protector - File protection and hiding
> library for Win32
> developers.
> Alfa Registry Monitor - Registry monitoring library
> for Win32
> developers.
> Alfa Registry Protector - Registry protection
> library for Win32
> developers.
>
>
>
>
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@compelson.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/
—
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com