FltReissueSynchronousIo() as Kernel Mode and SeAccessCheck()

NTFSD
1

Hello,

While developing a file system driver I’ve encountered a strange behavior that?s related to Fileinfo.sys mini-filter and my file system ACLs checks (on Windows 7 32bits).

When current security descriptor information indicates that a file cannot be opened by an application with the desired access, access denied is returned by the file system driver. When the failure status arrives the Fileinfo?s post-operation callback, it issues the request again with FltReissueSynchronousIo(), this time with RequestorMode = KernelMode.

Obviously when I call SeAccessCheck() with RequestorMode = KernelMode I return STATUS_SUCCESS and the application successfully retrieves a valid handle.

I assume I don?t handle this case in a correct way but I?m not sure what I should look for.

Currently I’ve tried to check if either IO_FORCE_ACCESS_CHECK or SL_FORCE_ACCESS_CHECK are present but that is not the case.

When I’ve checked the same scenario with NTFS, the application failed to open the handle (with access denied), and while debugging it I could see that Fileinfo gets access denied as well after the IO is being re-issued (which means that NTFS handles it correctly somehow).

Does anyone know what would be the correct way to detect this scenario?

Thanks,
Regards

2

Have you tried the ExGetPreviousMode() API?

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: xxxxx@gmail.com
To: “Windows File Systems Devs Interest List”
Sent: 4/29/2015 8:01:35 AM
Subject: [ntfsd] FltReissueSynchronousIo() as Kernel Mode and
SeAccessCheck()

>Hello,
>
>While developing a file system driver I’ve encountered a strange
>behavior that?s related to Fileinfo.sys mini-filter and my file system
>ACLs checks (on Windows 7 32bits).
>
>When current security descriptor information indicates that a file
>cannot be opened by an application with the desired access, access
>denied is returned by the file system driver. When the failure status
>arrives the Fileinfo?s post-operation callback, it issues the request
>again with FltReissueSynchronousIo(), this time with RequestorMode =
>KernelMode.
>
>Obviously when I call SeAccessCheck() with RequestorMode = KernelMode I
>return STATUS_SUCCESS and the application successfully retrieves a
>valid handle.
>
>I assume I don?t handle this case in a correct way but I?m not sure
>what I should look for.
>
>Currently I’ve tried to check if either IO_FORCE_ACCESS_CHECK or
>SL_FORCE_ACCESS_CHECK are present but that is not the case.
>
>When I’ve checked the same scenario with NTFS, the application failed
>to open the handle (with access denied), and while debugging it I could
>see that Fileinfo gets access denied as well after the IO is being
>re-issued (which means that NTFS handles it correctly somehow).
>
>Does anyone know what would be the correct way to detect this scenario?
>
>Thanks,
>Regards
>
>
>—
>NTFSD is sponsored by OSR
>
>OSR is hiring!! Info at http://www.osr.com/careers
>
>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

3

Thanks Peter,

That solves the issue! I wasn’t aware such a routine exists.

So the general rule regarding it is to use the ExGetPreviousMode?s result every time the IRP?s requestor mode is KernelMode for ACL checking?

Thanks!

4

> So the general rule regarding it is to use the ExGetPreviousMode?s result every time the IRP?s

I think Io calls ExGetPreviousMode to fill Irp->RequestorMode when initiating the IRP.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com