FILE_OBJECT Confusion

All,

I’ve looked through the lists and managed to get myself confused about the
relationships between FILE_OBJECTS and open instances of files. This is a
basic question and hopefully I wont annoy anyone by asking it…

So, Is my thinking true?:

  1. File objects represent an open instance of a file/directory (allocated as
    a result of - for example - a ZwCreateFile/ZwOpenFile call).
  2. A number of different FILE_OBJECTS can represent the same logical
    file/directory. They can be linked by the FSRTL_ADVANCED_FCB_HEADER (if the
    file system supports them).

If they are true, can I do the following things?

  1. On receipt of a read/write operation can I determine the owning process
    of an open file instance by asserting that a specific FILE_OBJECT is linked
    to the process that issued the IRP_MJ_CREATE.
  2. If I wanted to link all instances of IO to a file based on one
    IRP_MJ_CREATE operation I saw, I could use a stream context (which under the
    hood is be linked to the FSRTL_ADVANCED_FCB_HEADER)?

Sorry if you’ve answered these questions before, but I did check out the
lists and like I said, got myself confused!

Many thanks in advance!

Carl

Hiya

You seem to be pretty much there.

Let’s assume file system supports FSTRL_ADV … for now. Then, all the file
objects which exist for the same directory/file/stream at the same time have
the same value in FileObject->FsContext. Capturing the user context in
IRP_MJ_CREATE and using that as the user context for subsequent i/o for the
same FILE_OBJECT is a useful approach; in mini-filter-land this means same
STREAM_HANDLE_CONTEXT. But do bear in mind DuplicateHandle and inheritance
of handles across CreateProcess - the process which created the handle, the
FILE_OBJECT, might not be the process which issues ‘this’ i/o for the
FILE_OBJECT.

What makes less sense to my mind (well, my mind, anyway!) is asoociation of
captured user context with FileObject->FsContext, in mini-filter-land this
means STREAM_CONTEXT. Here realize that different user contexts, processes,
etc, can have independent handles to the file, and hence independent
FILE_OBJECTs.

Does that help?

Best Wishes
Lyndon

“TMA” wrote in message news:xxxxx@ntfsd…
> All,
>
> I’ve looked through the lists and managed to get myself confused about the
> relationships between FILE_OBJECTS and open instances of files. This is a
> basic question and hopefully I wont annoy anyone by asking it…
>
> So, Is my thinking true?:
>
> 1. File objects represent an open instance of a file/directory (allocated
> as a result of - for example - a ZwCreateFile/ZwOpenFile call).
> 2. A number of different FILE_OBJECTS can represent the same logical
> file/directory. They can be linked by the FSRTL_ADVANCED_FCB_HEADER (if
> the file system supports them).
>
> If they are true, can I do the following things?
> 1. On receipt of a read/write operation can I determine the owning process
> of an open file instance by asserting that a specific FILE_OBJECT is
> linked to the process that issued the IRP_MJ_CREATE.
> 2. If I wanted to link all instances of IO to a file based on one
> IRP_MJ_CREATE operation I saw, I could use a stream context (which under
> the hood is be linked to the FSRTL_ADVANCED_FCB_HEADER)?
>
> Sorry if you’ve answered these questions before, but I did check out the
> lists and like I said, got myself confused!
>
> Many thanks in advance!
>
> Carl
>
>
>

>>1. On receipt of a read/write operation can I determine the owning process of an open file instance >>by asserting that a specific FILE_OBJECT is linked to the process that issued the IRP_MJ_CREATE.

May be not directly an answer to your question, but will add something.

you can check for user process in Pre Create as they are comes in same process context. There in create handler you can check if it the process you are targetting and create a stream handle context in case you want to keep information on per handle base. or else you can create a stream context if you want to keep information related to a stream(instead of handle/FIleObject).

Why this? Coz your later IRPs like read/write can come in some arbitrary process context.

Thanks,
Aditya

Hi Aditya,

Thanks for the response!

I was just looking to fill in a few gaps in my understanding. I just wanted
clear up the relationship between FILE_OBJECTS, handles and then as you say
stream and handle contexts before we get anywhere near a compiler! I think
I’ve got process context and IRQL straight and therefore what I can do in
specific situations. In essence, I’m building up a list of rules I must
adhere to and facts that *should* be true before I go ahead and start
writing code.

Carl

wrote in message news:xxxxx@ntfsd…
>>>1. On receipt of a read/write operation can I determine the owning
>>>process of an open file instance >>by asserting that a specific
>>>FILE_OBJECT is linked to the process that issued the IRP_MJ_CREATE.
>
> May be not directly an answer to your question, but will add something.
>
> you can check for user process in Pre Create as they are comes in same
> process context. There in create handler you can check if it the process
> you are targetting and create a stream handle context in case you want to
> keep information on per handle base. or else you can create a stream
> context if you want to keep information related to a stream(instead of
> handle/FIleObject).
>
> Why this? Coz your later IRPs like read/write can come in some arbitrary
> process context.
>
> Thanks,
> Aditya
>

Generally, You can see a file object in kernel as you see a handle in user mode.

now there there are three different contexts,

streamhandle: use this when you want to maintain a context per file object, so for n number of fileobjects for a particular stream, you will have n streamhandle context.

stream: use this when you want to maintain a context per stream, so for n number of fileobjects for a particular stream, you will have 1 stream context.

File (Vista onwards): If a file have n streams, and you want to maintain a context for file (not for a individual stream). go for it.

I think you can search this information easily, on internet and even on OSR. Just try again, you may got few old thread which clarify all your doubt.

Happy learning.
Aditya

TMA wrote:

  1. On receipt of a read/write operation can I determine the owning
    process of an open file instance by asserting that a specific
    FILE_OBJECT is linked to the process that issued the IRP_MJ_CREATE.

I’m not clear about what’s being asked here, but be careful for two things:

  1. Reads/writes for a given FileObject can occur in arbitary process
    context. The FileObject may be used to back Cc/Mm’s section, in which
    case, reads/writes can occur after the process has terminated.
  2. Handles can be inherited and duplicated. Process A can open a file
    and pass a handle to process B. A and B can then generate IO via the
    same FileObject. Alternatively, A can terminate, leaving B performing IO.

Just to be clear - attempting to access the process which opened a
FileObject during read/write is not safe, as that process is not
guaranteed to exist.

  • M