Best way to ignore remote mailslot/named pipe activity in file system filter driver

NTFSD
1

Hello,

I am continuing the discussion that I had on the topic at http://www.osronline.com/showThread.cfm?link=217431 since that thread aged and I am not able to post a new response there.

Just to re-iterate quickly: We want our filter driver to ignore the named pipe/mailslot initiated over lanmanredirector e.g. When code running on machine A opens a named pipe on machine B, the filter driver running on machine A notices the access to \B\pipe\pipename path and we want the filter driver to ignore this.

I tried the option of checking FO_NAMED_PIPE and FO_MAILSLOT flags in PostOpCreate and I noticed couple of caveats.

  1. The FO_MAILSLOT flag is NOT set in PostOpCreate for mailslot file object.
  2. Although, FO_NAMED_PIPE is set correctly for the file object representing named pipe, I see that it is also set for fileobject pointing to \B\IPC$? Is this expected? Can this flag be set in other non-pipe cases?

Let me know.

Thanks.
-Prasad

2

Can someone answer this please?

Thanks.
-Prasad

3

It looks like you will need to filter based on the name of the share to detect remote pipes and mailslots. As you’ve seen the redirector does not set FO_MAILSLOT and (I haven’t confirmed this yet) appears to set FO_NAMED_PIPE on some file objects not backed by NPFS . Based on your input we will try to have a better story in the future.

Thanks,
Scott [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@vmware.com
Sent: Tuesday, January 24, 2012 9:16 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Best way to ignore remote mailslot/named pipe activity in file system filter driver

Can someone answer this please?

Thanks.
-Prasad

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Thanks Scott. So, this basically goes back to your message #3 in my original post at http://www.osronline.com/showThread.cfm?link=217431.

On that post, you mentioned to query FLT_FILE_NAME_OPENED name and then check the share for “pipe” or “mailslot”. Can I just parse fltObjects->FileObject->FileName instead? The PCFLT_RELATED_OBJECTS fltObjects is passed to PreOpCreate.

Let me know.

Thanks.
-Prasad

5

> On that post, you mentioned to query FLT_FILE_NAME_OPENED name and then check the share

for “pipe” or “mailslot”.

If you go heuristic way, then also find the device/driver objects in question and look at whether the DrvO name contains “msfs” or “npfs”. Even though you will not be able to catch the client ends of the network pipes (they are maintained by RDBSS and not NPFS), this is a good idea.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

6

I think it would be preferable to use the filter manager API which does the same name parsing from the file object for you.

Note for pipes, you may be able to rely on the FO_NAMED_PIPE in post create after all. Besides named pipes, the connection to the IPC$ (and only to the IPC$) is also explicitly marked by the redirector as a pipe connection to the IPC$. It is a file that supports pipe semantics, though not backed by the NPFS on the server side.

Thanks,
Scott [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@vmware.com
Sent: Monday, January 30, 2012 3:37 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Best way to ignore remote mailslot/named pipe activity in file system filter driver

Thanks Scott. So, this basically goes back to your message #3 in my original post at http://www.osronline.com/showThread.cfm?link=217431.

On that post, you mentioned to query FLT_FILE_NAME_OPENED name and then check the share for “pipe” or “mailslot”. Can I just parse fltObjects->FileObject->FileName instead? The PCFLT_RELATED_OBJECTS fltObjects is passed to PreOpCreate.

Let me know.

Thanks.
-Prasad

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

Thanks Scott and Maxim for your responses.

Scott, I agree with your advice to use the filter manager API. However, I had concerns about the overheads of calling FltGetFileNameInformation on each PreOpCreate just to check if the FILE_OBJECT is pointing to named pipe/mailslot. Hence, I was asking if it is safe to directly parse fltObjects->FileObject->FileName instead (after doing standard NULL, length checks etc). Is it possible to have a FILE_OBJECT referring to named pipe/mailslot when fltObjects->FileObject->FileName is not having the pattern \servername*\MAILSLOT.… OR \servername\PIPE.…?

Maxim, I am not sure about what you mean by client ends of the network pipe here? When machine A creates a named pipe say “hello” and machine B connects to it, our filter driver running on machine B sees PreOpCreate with FileName=\A\PIPE\Hello. We want to ignore this request and return FLT_PREOP_SUCCESS_NO_CALLBACK from PreOpCreate. Are you saying that, in this case, Drv0 name will be msfs/npfs? Filter on machine B doesn’t see this request at all since it will be directly served by NPFS and our filter doesn’t attach to it anyways.

Thanks.
-Prasad

8

It isn’t ideal, but a pre create open name query should not be a lot of overhead relative to the overall remote create. Fltmgr is just allocating some memory and parsing the fileobject->Filename. Another benefit is if anyone else needs the name, it will now be in fltmgr’s name cache.

For a mailslot you should always have the \servname*\MAILSLOT\ format. For a pipe, as you’ve seen you might get IPC$. I’d recommend checking the fileobject flags for FO_NAMED_PIPE in post create.

Thanks,
Scott [MSFT]
This posting is provided “AS IS” with no warranties, and confers no rights.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@vmware.com
Sent: Tuesday, January 31, 2012 12:23 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Best way to ignore remote mailslot/named pipe activity in file system filter driver

Thanks Scott and Maxim for your responses.

Scott, I agree with your advice to use the filter manager API. However, I had concerns about the overheads of calling FltGetFileNameInformation on each PreOpCreate just to check if the FILE_OBJECT is pointing to named pipe/mailslot. Hence, I was asking if it is safe to directly parse fltObjects->FileObject->FileName instead (after doing standard NULL, length checks etc). Is it possible to have a FILE_OBJECT referring to named pipe/mailslot when fltObjects->FileObject->FileName is not having the pattern \servername*\MAILSLOT.… OR \servername\PIPE.…?

Maxim, I am not sure about what you mean by client ends of the network pipe here? When machine A creates a named pipe say “hello” and machine B connects to it, our filter driver running on machine B sees PreOpCreate with FileName=\A\PIPE\Hello. We want to ignore this request and return FLT_PREOP_SUCCESS_NO_CALLBACK from PreOpCreate. Are you saying that, in this case, Drv0 name will be msfs/npfs? Filter on machine B doesn’t see this request at all since it will be directly served by NPFS and our filter doesn’t attach to it anyways.

Thanks.
-Prasad

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer