IO_IGNORE_SHARE_ACCESS_CHECK and file sharing (redux)

NTFSD
1

Hi all,

On a couple of occasions, we?ve been surprised at the outcome of the following test:

Open an existing file via FltCreateFileEx2 (or similar) with:
DesiredAccess = FILE_READ_DATA
ShareAccess = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE
Flags = IO_IGNORE_SHARE_ACCESS_CHECK

While the file handle is still open, open the same file with:
DesiredAccess = FILE_WRITE_DATA
ShareAccess = 0
Flags = 0

We expect the second open to fail with STATUS_SHARING_VIOLATION, since the file is already open for READ and the sharing flags are incompatible.

However, the second open succeeds. We find the same regardless of the desired access of the second open ? FILE_READ_DATA and DELETE also work. We?ve reproduced this on Windows 7 SP1 as well as Windows 10 SP3.

When I finally decided to post my puzzlement to NTFSD, the site was down due to the OSR office move. Later I found a similar observation, without explanation:
https://www.osronline.com/showthread.cfm?link=152866

As it turns out, if IO_IGNORE_SHARE_ACCESS_CHECK is passed in, IoCheckShareAccess does not update the counts in the SHARE_ACCESS struct of the FCB. So, subsequent opens are not affected by the access permissions or share access.

Given this undocumented behavior, I wrote a blog post. I recently came across quite a complicated approach to avoid sharing violations – this way is much easier and should be made more obvious.

https://needleinathreadstack.wordpress.com/2018/04/09/io_ignore_share_access_check

Feedback is most welcome. Thanks,

Alnoor

2

It’s funny because I have always assumed IO_IGNORE_SHARE_ACCESS_CHECK “sneaks in” and thus does not affect current or future sharing requests. However, this wasn’t based on any documentation or testing, just an assumption that that must be the way it works.

Clearly you assumed it worked a different way and were burned by it. In the end, we all end up paying for assuming at some point :slight_smile: Nice thing to point out in a blog post and the documentation could certainly use an update.

-scott
OSR
@OSRDrivers

3

Thanks. We’re quite happy about this behavior, as it exonerates our component in a customer issue.

The lack of documentation does hurt though – we wasted many hours exploring theories that had no basis in reality.

Alnoor