I had about 15 minutes this morning waiting for some guys to fix the single engine plane that would take me further into this country (which shall remain nameless)  so I decided to whip open my handy dandy laptop and do some ifskit “.h” file scanning, which I haven’t done in a LONG time.   In the process of looking over “ntifs.h” I noticed a new flag in the FILE_OBJECT flags field named FO_REMOTE_ORIGIN.  Being the curious guy that I am, I started searching for the word “Remote” in the IFS Kit Documentation and found the 2 interesting functions IoSetFileOrigin and IoIsFileOriginRemote which were introduced in Windows 2000.

IoSetFileOrigin, according to the IFS kit documentation, allows the caller to specify whether a given file object is for a remote create request.   If the Remote Boolean Parameter in the call is set to TRUE, then this function will set the FO_REMOTE_ORIGIN flag in the file object.  The documentation also states that network file systems should call this function in their Servers for any file objects that are created to satisfy a create request from a network client.

IoIsFileOriginRemote, according to the IFS kit documentation, allows the caller to determine whether a given file object is for a remote create request.   This routine returns a BOOLEAN indicating whether or not the FO_REMOTE_ORIGIN flag in the FILE_OBJECT is set.  There is supposed to be a trick to using this function: You can only call it after the create is fully complete (so, you can’t check the status of a file in either the pre- or post- create IRP processing paths).

Knowing about these 2 routines can be very helpful for file system developers because they now have the ability to indicate to the OS where the file was opened from, i.e. locally or remotely.   Likewise file system filter developers can check this bit if they need to determine locality also.

I guess my next task will be to write a filter to determine who sets this bit.   If I read the documentation correctly I would assume that “SRV” would do this.

A flag that, IF SET, suggests remote origin, and, if it isn't set????

We'll whaddyaknow, we still can't tell!

"A fuzzy flag"

FOR SUCH FLAGS TO HAVE FULL VALUE REQUIRES A RETROSPECTIVE RULE:-

"ALL redirectors (current & historical) MUST set the flag FO_REMOTE_ORIGIN for all remote requests that they forward. Any other kernel components doing file I/O should clear this flag.

Now I don't know about you, but I can't see that happening, given the low profile of this flag!

So we still don't have a silver bullet, and can't expect one. A flag is not really up to the challenge.

Of course, you'd be fairly safe to assume, that if a file is created by a USER MODE process then its definitely a locally generated request (but even then it could be forwarded off-host somewhere by that user process).

Assuming all kernel requests to be remote might not be a bad approximation for you, for example if you're filter is decrypting user data for local consumption.

What else can you do? I think you're be obliged to look at the SIDS, and you can probably kiss your performance goodnight.

My guess is that this is the real value of this flag.

Having this flag might help some filter drivers avoid some work decoding and checking security structures on file open (sometimes).