OSRLogo
OSRLogoOSRLogoOSRLogo x Seminar Ad
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Wed, 13 Dec 2017     115626 members

   Login
   Join


 
 
Contents
  Online Dump Analyzer
OSR Dev Blog
The NT Insider
Downloads
ListServer / Forum
Driver Jobs
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

Files Opened as a result of a Remote Request

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.

Related Articles
Are You Being SRVed? - The Lan Manager File Server on NT
Duplicate Disk Writes
Back to Basics - An Introduction to Transactions

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

"FO_REMOTE_ORIGIN"
Just to let you know we have seen that SRV does set the FO_REMOTE_ORIGIN bit. So the question is do other file servers use these services.

Rating:
21-Jul-03, Mark Cariddi


"FO_REMOTE_ORIGIN"
So what exactly HAVE we got here?

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

Rating:
21-Jul-03, Jack Heeley


Post Your Comments.
Print this article.
Email this article.

Writing WDF Drivers I: Core Concepts
LAB

Nashua (Amherst), NH
15-19 May 2017

Writing WDF Drivers II: Advanced Implementation Techniques
LAB

Nashua (Amherst), NH
23-26 May 2017

Kernel Debugging and Crash Analysis
LAB

Dulles (Sterling), VA
26-30 Jun 2017

Windows Internals and Software Driver Development
LAB

Nashua (Amherst), NH
24-28 Jul 2017

 
 
 
 
x
LetUsHelp
 

Need to develop a Windows file system solution?

We've got a kit for that.

Need Windows internals or kernel driver expertise?

Bring us your most challenging project - we can help!

System hangs/crashes?

We've got a special diagnostic team that's standing by.

Visit the OSR Corporate Web site for more information about how OSR can help!

 
bottom nav links