User Defined ECPs

All,
I’m developing a mini filter driver that is targeting a client/server
environment. The environment is Windows 10 and up. I need the client to
communicate some local information over to the server. Can someone please
tell me if a user defined ECP that is attached in the PreCreate callback on
a client machine will show up in the list of ECPs on the server?
TIA!

I believe not. But SMB is a moving target (this is SMB?)

EA’s do get transferred…
/Rod

Thanks Rod - I appreciate it. That’s a possible solution.
What I’m trying to do specifically, is to determine the local process
(e.g.: wordpad.exe) that the client used to open the file. I could use the
EA’s to effectively communicate the information over to the server.
However, has anyone come up with an effective technique for doing this?

On Wed, Aug 1, 2018 at 1:49 AM, Rod Widdowson <
xxxxx@lists.osr.com> wrote:

> I believe not. But SMB is a moving target (this is SMB?)
>
> EA’s do get transferred…
> /Rod
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

EAs definitely go to the server. You just need to be REALLY sure that you’re
running on the server so that you can strip it out on the other end,
otherwise the file will be created with your EA…

I don’t know any other way to get additional information passed in band with
the create request from the client to the server.

You could muck with the name, but then you have the same problem as the EA
if you’re not on the server. I also tend to avoid anything that involves
changing the name for encoding data. Names are hard enough and when you
start messing with them it eventually leaks to the user and gets confusing
(i.e. their A/V engine pops a toast notification that it found a virus in
Foo.doc.{WORDPAD.EXE})

-scott
OSR
@OSRDrivers

At this point I have this solution up and running but I’m running into
situation that I believe is a race condition.
Just for back ground: I’m trying to come up with a solution for when a
client accesses files on a server, the client can report the name of the
process that is being used to access the file. To do this the client side
driver attaches extended attributes at post create time (where the extended
attributes contain the name of the accessing process). The server side
driver then reads and clears the extended attributes when an operation of
interest occurs. However I’m running into a situation that I believe is a
race condition. The scenario is as follows: On the client side, Explorer is
constantly querying the server side directory resulting in “Explorer.exe”
being added to the file as extended attributes. Eventually, a user tries to
read a file using wordpad. Sometimes, when the extended attributes are
queried by the read handler on the server side, explorer is returned
instead of wordpad. At this point I believe that this is an implication of
two processes simultaneously accesses a shared resource without any type of
synchronization.

Questions:
In Scott’s post, he seemed to imply that the AE’s could be queried and then
removed on the server side before they are actually appended to the file.
Is there actually a way to do this?
Is there a way for the client to synchronize access to the remote file such
that a process is blocked until the first process completes it’s access?
Would an OP_LOCK provide this kind of synchronization?

Any suggestions would be greatly appreciated.

On Tue, Aug 14, 2018 at 8:40 AM Scott Noone <
xxxxx@lists.osr.com> wrote:

> EAs definitely go to the server. You just need to be REALLY sure that
> you’re
> running on the server so that you can strip it out on the other end,
> otherwise the file will be created with your EA…
>
> I don’t know any other way to get additional information passed in band
> with
> the create request from the client to the server.
>
> You could muck with the name, but then you have the same problem as the EA
> if you’re not on the server. I also tend to avoid anything that involves
> changing the name for encoding data. Names are hard enough and when you
> start messing with them it eventually leaks to the user and gets confusing
> (i.e. their A/V engine pops a toast notification that it found a virus in
> Foo.doc.{WORDPAD.EXE})
>
> -scott
> OSR
> @OSRDrivers
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

Are you aware that client systems can cache file data? A single read request
on the server might supply data to several different applications on the
client. It’s not as if you’re going to see a read from every application
that reads the file data (it would be REALLY inefficient if it worked that
way).

In fact, it doesn’t even really work this way in the local case. Drag and
drop a text file and then open the file in Notepad. You’ll note that you
don’t see any read requests generated by Notepad.

My point about EAs is that they can be specified along with the open itself
(see prototype of ZwCreateFile). These are tunneled along with the other
create parameters by SMB. This allows you to attach additional information
inline with the IRP_MJ_CREATE request.

If your filter is on the server, you can see the EA buffer along with the
IRP_MJ_CREATE request and interpret its contents. It can then be stripped
out before the IRP_MJ_CREATE hits the file system.

To be clear: I don’t recommend this mechanism because if you’re NOT running
on the server, you’re not there to strip it out, and then you’re stuffing
random EAs into the user’s files. At a minimum this is untidy. But, as I
said in my previous response, “I don’t know any other way to get additional
information passed in band with the create request from the client to the
server.”

Synchronizing client access to a file should just be a matter of putting a
lock in the Stream Context and serializing operations. But, I don’t know if
this matters as it’s not clear that your design actually works in any case.

Lastly, oplocks are entirely unrelated here as they don’t actually have
anything to do with locking (they’re about data caching and, strangely
enough, avoiding sharing violations).

-scott
OSR
@OSRDrivers