RE: ... 'shadow device object'... (more)

OSR_Community_User · July 17, 2000, 7:39pm

assertion while using ‘shadow device object’ recursion removal techniqueAn
even more secure mechanism may be to use a service and have the threads
always run in the context of the service. You can use an IOCTL to register
the service with the driver to get process context. This allows you to use
flexible security policies on the “phantom” file you are accessing; or not.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Monday, July 17, 2000 4:03 PM
To: File Systems Developers
Subject: [ntfsd] assertion while using ‘shadow device object’ recursion
removal te chnique

I’ve implemented my interpretation of the ‘shadow device object’
technique that has been discussed over the last couple days on this group.
Basically, when creating my filter device I create a second ‘shadow’ device
with a unique name. This shadow device is, of course, not in the file
system device stack.

In my filter’s IRP_MJ_CREATE handler, if I have to call
ZwCreateFile, instead of initializing the file name with the partition’s
device object’s name prepended, I prepend the name of my ‘shadow’ device:
(i.e. \Device\shadow_0\somefile.txt). I then call ZwCreateFile.

Also in my filter’s IRP_MJ_CREATE handler is a special case to
handle creates redirected to the ‘shadow’ device object. (i.e.
ZwCreate(\Device\shadow_0\somefile.txt). If a create comes in for the
shadow device object the special case simply forwards the create to the fsd
with IoCallDriver.

This technique works well 99% of the time. Occasionally, however,
I get an assertion from the FSD:

*** Assertion failed: No correspondence btwn file and device in
irp((IrpSp->FileObject->Vpb == NULL) && ((IrpSp->FileObject->DeviceObject !=
NULL) && (IrpSp->FileObject->DeviceObject->Vpb != NULL) &&
(IrpSp->DeviceObject == IrpSp->FileObject->DeviceO

bject->Vpb->DeviceObject))) || ((IrpSp->FileObject->Vpb != NULL) &&
(IrpSp->DeviceObject == IrpSp->FileObject->Vpb->DeviceObject)) ||
!FlagOn( Vcb->VcbState, VCB_STATE_VOLUME_MOUNTED ))

*** Source File: D:\nt\private\ntos\cntfs\strucsup.c, line 6670

This may not be enough to tell what I’ve done wrong, but its all
I’ve got now. I’ll update the thread with some more information tommorrow,
after I continue to debug the problem (I’m just hoping the problem will be
obvious to one of you and you can save me time :))

Thanks,
Joel

OSR_Community_User · July 17, 2000, 7:58pm

assertion while using ‘shadow device object’ recursion removal
techniqueSorry if I seem to be on a tangent, but here is a little more…

Create a new function called ZwCreateFileEx(…) and have the same
parameters as ZwCreateFile() except add a new parameter that is the process
ID.
In the ZwCreateFileEx(…) routine, create a system thread in the
requested process (NULL == system process), pass the parameters in a
context structure to the thread.
The thread will call ZwCreateFile and signal and event when done
When thread done, terminate the thread and then return from
ZwCreateFileEx().

You may even consider createing other ZwXxxEx functions for ZwWriteFile(),
etc… This would allow you to have all of your private I/O to come from a
know process/thread. Your filter dispatcher can do the check for the thread
on entry and simply pass its calls down. You can also create a small pool of
threads rahter than creating a thread each time. This gets a little more
tricky.

Even more exotic thought… Use the filter to keep a reference count of file
objects opened for a given worker thread/process. When this count goes to
zero, you can terminate the thread. This way, you will always have a system
thread running in a process that has reference to files that you are
tracking or monitoring… Oooooo, I like this.

OK, I am done, I need another beer

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Jamey Kirby
Sent: Monday, July 17, 2000 4:31 PM
To: File Systems Developers
Subject: [ntfsd] RE: … ‘shadow device object’… (more)

An even more secure mechanism may be to use a service and have the threads
always run in the context of the service. You can use an IOCTL to register
the service with the driver to get process context. This allows you to use
flexible security policies on the “phantom” file you are accessing; or not.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Smith, Joel
Sent: Monday, July 17, 2000 4:03 PM
To: File Systems Developers
Subject: [ntfsd] assertion while using ‘shadow device object’ recursion
removal te chnique

I’ve implemented my interpretation of the ‘shadow device object’
technique that has been discussed over the last couple days on this group.
Basically, when creating my filter device I create a second ‘shadow’ device
with a unique name. This shadow device is, of course, not in the file
system device stack.

In my filter’s IRP_MJ_CREATE handler, if I have to call
ZwCreateFile, instead of initializing the file name with the partition’s
device object’s name prepended, I prepend the name of my ‘shadow’ device:
(i.e. \Device\shadow_0\somefile.txt). I then call ZwCreateFile.

Also in my filter’s IRP_MJ_CREATE handler is a special case to
handle creates redirected to the ‘shadow’ device object. (i.e.
ZwCreate(\Device\shadow_0\somefile.txt). If a create comes in for the
shadow device object the special case simply forwards the create to the fsd
with IoCallDriver.

This technique works well 99% of the time. Occasionally,
however, I get an assertion from the FSD:

*** Assertion failed: No correspondence btwn file and device in
irp((IrpSp->FileObject->Vpb == NULL) && ((IrpSp->FileObject->DeviceObject !=
NULL) && (IrpSp->FileObject->DeviceObject->Vpb != NULL) &&
(IrpSp->DeviceObject == IrpSp->FileObject->DeviceO

bject->Vpb->DeviceObject))) || ((IrpSp->FileObject->Vpb != NULL) &&
(IrpSp->DeviceObject == IrpSp->FileObject->Vpb->DeviceObject)) ||
!FlagOn( Vcb->VcbState, VCB_STATE_VOLUME_MOUNTED ))

*** Source File: D:\nt\private\ntos\cntfs\strucsup.c, line 6670

This may not be enough to tell what I’ve done wrong, but its all
I’ve got now. I’ll update the thread with some more information tommorrow,
after I continue to debug the problem (I’m just hoping the problem will be
obvious to one of you and you can save me time :))

Thanks,
Joel

OSR_Community_User · July 18, 2000, 12:15am

assertion while using ‘shadow device object’ recursion removal technique>You
may even consider createing other ZwXxxEx functions for ZwWriteFile(),

etc… This would allow you to have all of your private I/O to come from a
know
process/thread.

This is maybe an overkill - security stuff is checked on CREATE only.

Max

OSR_Community_User · July 18, 2000, 2:05am

Yes. You are correct, but the file handle is process sensitive.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Monday, July 17, 2000 9:03 PM
To: File Systems Developers
Subject: [ntfsd] RE: … ‘shadow device object’… (more)

assertion while using ‘shadow device object’ recursion removal
technique>You
may even consider createing other ZwXxxEx functions for ZwWriteFile(),
>etc… This would allow you to have all of your private I/O to
come from a
know
>process/thread.

This is maybe an overkill - security stuff is checked on CREATE only.

Max

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

OSR_Community_User · July 18, 2000, 11:54am

> Yes. You are correct, but the file handle is process sensitive.

AFAIK the handle created by ZwCreateFile (NtCreateFile with
ExGetPreviousMode() == KernelMode) is a kernel handle belonging to the
System process - am I wrong?

Max

OSR_Community_User · July 18, 2000, 12:11pm

No. The file handle created by ZwCreateFile() is context sensitive the the
process that it was opened in.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Tuesday, July 18, 2000 7:40 AM
To: File Systems Developers
Subject: [ntfsd] RE: … ‘shadow device object’… (more)

> Yes. You are correct, but the file handle is process sensitive.

AFAIK the handle created by ZwCreateFile (NtCreateFile with
ExGetPreviousMode() == KernelMode) is a kernel handle belonging to the
System process - am I wrong?

Max

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

OSR_Community_User · July 18, 2000, 12:19pm

At least as far 4.0 is concerned, you are wrong. The handle is still
allocated in the handle table of the current process regardless of the
previous mode. Unless you’re actually in the system process context which
appears in Task Manager as “System,” then the handle is not allocated in the
system process’s handle table. The “System” process really is a legitimate
process. It even has its own user virtual address space although I once saw
some documentation that claimed otherwise.

I don’t think things have changed with respect to this in W2K.

Rob

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, July 18, 2000 9:40 AM
To: File Systems Developers
Subject: [ntfsd] RE: … ‘shadow device object’… (more)

> Yes. You are correct, but the file handle is process sensitive.

AFAIK the handle created by ZwCreateFile (NtCreateFile with
ExGetPreviousMode() == KernelMode) is a kernel handle
belonging to the
System process - am I wrong?

Max

You are currently subscribed to ntfsd as: xxxxx@nsisw.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

OSR_Community_User · July 18, 2000, 2:33pm

I thought that is what I said; “The handle is process context sensitive”.
So, I guess I am right

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Rob Fuller
Sent: Tuesday, July 18, 2000 9:18 AM
To: File Systems Developers
Subject: [ntfsd] RE: … ‘shadow device object’… (more)

At least as far 4.0 is concerned, you are wrong. The handle is still
allocated in the handle table of the current process regardless of the
previous mode. Unless you’re actually in the system process context which
appears in Task Manager as “System,” then the handle is not
allocated in the
system process’s handle table. The “System” process really is a
legitimate
process. It even has its own user virtual address space although
I once saw
some documentation that claimed otherwise.

I don’t think things have changed with respect to this in W2K.

Rob

> -----Original Message-----
> From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
> Sent: Tuesday, July 18, 2000 9:40 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: … ‘shadow device object’… (more)
>
>
> > Yes. You are correct, but the file handle is process sensitive.
>
> AFAIK the handle created by ZwCreateFile (NtCreateFile with
> ExGetPreviousMode() == KernelMode) is a kernel handle
> belonging to the
> System process - am I wrong?
>
> Max
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nsisw.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

OSR_Community_User · July 19, 2000, 1:48am

> process. It even has its own user virtual address space although I once
saw

some documentation that claimed otherwise.

Yes, it has - and it is possible to allocate memory there and use it.

Max