Using FltCreateFile on paths from MUP that are Normalized

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.

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).

.

@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.

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

Indeed forgot to include the hostname in the post.

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?

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

@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.