DesiredAccess is 0 in reissued IRP IRP_MJ_CREATE after redirection in post create when opend by word

NTFSD
1

Hi all,

I’m currently stuck in a problem with our mini-filter driver. The main
purpose of this driver is hsm but we added a new feature recently to handle
offline files on snapshot volumes. So whenever a previous version of an
offline file is accessed we do the following:

  1. Block pre create and copy the file from the snapshot to a temporary area.
    (note: the original file on the snapshot is marked with our own reparse
    point).
  2. Redirect the file in post create to the copied location in temp area

This goes all well until we use Word to open a file over the network. What
we see at first glance is that oplocks do not work correctly and when
accessing the file Word runs into some 30 seconds timeout. After further
analysis we detected that the reparsed create comes with a DesiredAccess
value of 0. This is why the oplock is not correctly broken during the
“reparsed create”. I did a test and patched the 0 value in pre-create to the
value used in the original create IRP and that did the trick.

This is an excerpt from the FileSpy output that shows the situation:

Original create on shadow copy:
723 14:54:05.659 0 System 3908 FEF13C40 IRP
FF3223B0 IRP_MJ_CREATE 00000884 00000000 819DE500
00000000 00000000 00000000 00000000
\Device\HarddiskVolumeShadowCopy4\t1\test-data\02_Office_files\DOC -
WSA\Windows Server System Reference Architecture EULA.rtf STATUS_REPARSE
FILE_OPEN CreOpts: 00200140 Access: 00020089 Share: 00000005 Attrib: 0
Reissued IRP:
724 14:54:05.659 0 System 3908 819F7E78 IRP
FF3223B0 IRP_MJ_CREATE 00000884 00000000 819DE500
E1EC4800 E1E6C818 00000000 00000000
E:$HSM_Cache$HSM_REC_HarddiskVolumeShadowCopy4_0001000000000077.dat
STATUS_SUCCESS FILE_OPEN CreOpts: 00200140 Access: 0 Share: 00000005
Attrib: 0 Result: FILE_OPENED

Questions:
a. Does DesiredAccess == 0 have a special meaning?
b. Is IO Manager altering DesiredAccess when reissuing the IRP during
reparse processing? (note: I checked the value in the original post create
and it is still the original)
c. Are we doing something completely wrong / am I on the wrong track with my
whole analysis?

Any tips, hints or help are greatly appreciated.

Regards,
Lars

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4769 (20100113) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

2

Comments inline…

Questions:
a. Does DesiredAccess == 0 have a special meaning?

FILE_ANY_ACCESS is defined as 0.

b. Is IO Manager altering DesiredAccess when reissuing the IRP during
reparse processing? (note: I checked the value in the original post
create
and it is still the original)

AFAIK, the I/O manager never changes the desired access value.

Regards,
Ayush Gupta
AI Consulting

3

I’d agree with what Ayush says, but here for completeness here are two other
points.

  • If the volume hasn’t been mounted yet then an open to "" with desired
    access goes to the physical device.
  • Over the network, in XP (and possibly 2K3) there was a particular
    behavior. When a file was opened in the kernel with desiredAccess 0 then
    you could write to that file object. Usually the remote server would only
    allow writes if the access was requested, so a file object opened for
    GENERIC_READ would fails attempts to write.

I don’t see that either of this would affect your situation. Have you
looked into what previouslyGrantedAccess is set to?

Rod

“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
> Comments inline…
>
>> Questions:
>> a. Does DesiredAccess == 0 have a special meaning?
>
> FILE_ANY_ACCESS is defined as 0.
>
>> b. Is IO Manager altering DesiredAccess when reissuing the IRP during
>> reparse processing? (note: I checked the value in the original post
>> create
>> and it is still the original)
>
> AFAIK, the I/O manager never changes the desired access value.
>
>
> Regards,
> Ayush Gupta
> AI Consulting
>
>

4

> - Over the network, in XP (and possibly 2K3) there was a particular

behavior. When a file was opened in the kernel with desiredAccess 0
then
you could write to that file object. Usually the remote server would
only
allow writes if the access was requested, so a file object opened for
GENERIC_READ would fails attempts to write.

Yikes… Was this a bug? Or a feature? :wink:

Regards,
Ayush Gupta
AI Consulting

5

Rod, Ayush,

thanks for your hints so far…

I checked some of the fields in AcessState:

AccessState: RemainingDesiredAccess=0x00000000, PreviouslyGrantedAccess=0x00020089, OriginalDesiredAccess=0x00020089.

One could see that both OriginalDesiredAccess and PreviouslyGrantedAccess contain the DesiredAcess values from the initial IRP_MJ_CREATE.

The question is:
What does that mean in the context of our word file issue?

Thanks,
Lars