Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

Using FltCreateFile on paths from MUP that are Normalized

Vadim_SirotnikovVadim_Sirotnikov Member Posts: 28
edited June 25 in NTFSD

I've recently met a scenario where I'm trying to open a file for reading from a mapped shared directory (Z:\file =>\\share\folder\file)

I'm using FltGetFileNameInformation/Unsafe (depending on whether I'm in a filesystem callback, or a loadimage / createprocess callback) to get the file name, and open it for some processing inside the kernel driver.

I see a difference depending on whether I'm using FLT_FILE_NAME_OPENED or FLT_FILE_NAME_NORMALIZED.

Using FLT_FILE_NAME_OPENED gets me\device\mup\;LanmanRedirector\;Z:(LUID)\share\folder\file and then FltCreateFile with the Mup Instance works ok.

Using FLT_FILE_NAME_NORMALIZED gets me \device\mup\share\folder\file and then FltCreateFile with the Mup Instance fails with STATUS_OBJECT_NAME_NOT_FOUND (0xC0000034).

This does not seem to be a permissions issue, since
1. I'm in the context of the process that has access the file in question, and when I'm not, I'm impersonating correctly
2. the error is NOT ACCESS_DENIED /STATUS_LOGON_FAILURE

Anyone cares to help me figure out what's up?
I've ran previous tests by accessing a remote folder directly, without mapping it, and had no issues accessing the normalized paths.

Comments

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,073

    No ideas, I’ve never had the second form fail for me. But where I’d look next would be

    • Tracing (procmon)on the server..
    • See how far down the name the object name not found occurs ( critically whether is the share or the path which fails).
  • Vadim_SirotnikovVadim_Sirotnikov Member Posts: 28
    edited June 25
  • Vadim_SirotnikovVadim_Sirotnikov Member Posts: 28

    @rod_widdowson said:
    No ideas, I’ve never had the second form fail for me. But where I’d look next would be

    Oddly enough, there is a different executable where it doesn't always fail, and I think that one requests some more permissions and privileges but I couldn't find any specific pattern.

    To be one the safe side, I tried impersonating the parent process (users's explorer.exe shell process which clearly had file access) but that did not help.


    * Tracing (procmon)on the server..
    * See how far down the name the object name not found occurs ( critically whether is the share or the path which fails).

    By that you mean to see whether it fails on the client or the server, right?

    Cause I'm not sure how to see which specific filter the error originates from, other than single stepping through assembly, which I'd rather not.

    I've done recording on the server in a previous round of debugging, where I saw that some requests arrive with a token of the client's station instead of the user (ie srv is impersonating domain\clientpc$ instead of domain\user).

    However, I'm not sure why it should return a status not found, as opposed to access denied/logon.

    Also when using normalized paths, I've often seen the path arrive with double backslash (ie \device\mup\sharename\\file) to which I found a single reference to, on a different thread here, as a thing that SMB does occasonally. This lead me to try reverting to FILE_OPENED to see improvement.

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,073

    By that you mean to see whether it fails on the client or the server, right?

    Yes (for the first)

     

    See how far down the name the object name not found occurs ( critically whether is the share or the path which fails).

     
    For this I mean the name \device\mup\share\folder\file try to open \device\mup\share\folder\file, then \device\mup\share\folder then \device\mup\share and see when the failures stop happening.

    The other thing to observe is that of course you don't need a filter to do much of this. Use FileSpy and it will allow you to create exactly the NtCreate/FltCreate that you want.

    It's worth noting that I am assuming that you have a transcription error and when you say \device\mup\share\folder\file you actually meant to type \device\mup\host\share\folder\file

  • Vadim_SirotnikovVadim_Sirotnikov Member Posts: 28
    Indeed forgot to include the hostname in the post.
  • Vadim_SirotnikovVadim_Sirotnikov Member Posts: 28
    edited June 26

    Ok, so did a bunch more testing today.

    It seems that there are several issues:

    1. Normalized paths do work, as long as I manually fix the double slash (which I almost always get when asking for normalized name).

    2. In most cases STATUS_OBJECT_NAME_NOT_FOUND is solvable by doing the correct impersonation.

    3. some executable files not only fail to open in FltCreate, but also fail to execute when I double click them, with an error box showing 0x80070002 (ERROR_FILE_NOT_FOUND). This is resolved by assigning access rights to 'Everyone' on them, so there is probably some point at which explorer or the loader try to access it with wrong impersonation.

    4. When passing \\device\mup\hostname\share\filename.ext to the usermode service, I also get an error of ERROR_FILE_NOT_FOUND (2L) when trying to access the UNC path \\hostname\share\filename.ext. Pheraps I need to use the mapped drive letter (eg. X:\filename.ext) instead?

  • rod_widdowsonrod_widdowson Member - All Emails Posts: 1,073

    I manually fix the double slash (which I almost always get when asking for normalized name).

    Some bugs never die !

    ISTR there used to be a "somewhat angry" comment in FAT about this. It is much politer now

  • Vadim_SirotnikovVadim_Sirotnikov Member Posts: 28

    @rod_widdowson said:

    I manually fix the double slash (which I almost always get when asking for normalized name).

    Some bugs never die !

    ISTR there used to be a "somewhat angry" comment in FAT about this. It is much politer now

    LOL
    I don't know who is to blame for this - the client is Win10, the share server is Win7 Sp1. Not sure I care enough to investigate.

    Meanwhile looking into why the usermode service fails to access the \\hostname directly.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE