Hmmm… I just wipped up a filter that pended all creates to a system
thread and passed them down, and it seems to work fine. I don’t know why I
thought passing down a create irp in a different context would cause things
to break… Thanks, I’ll fix my thread context sensitive code straight away.
-Joel
-----Original Message-----
From: Smith, Joel [mailto:xxxxx@ntpsoftware.com]
Sent: Wednesday, March 28, 2001 9:25 AM
To: File Systems Developers
Subject: [ntfsd] RE: Retrieving security information regarding thread call
ing IRP_MJ_C REATE
Wouldn’t it be bad form for a filter to pass on a create irp from a
context different than the context where the create was created (that’s a
mouthful)? Can’t a file system or filter assume that they are in the
context of the thread from which the create irp originated?
-----Original Message-----
From: Maxim S. Shatskih [ mailto:xxxxx@storagecraft.com
mailto:xxxxx ]
Sent: Monday, March 26, 2001 4:37 PM
To: File Systems Developers
Subject: [ntfsd] RE: Retrieving security information regarding thread
call ing IRP_MJ_C REATE
RE: [ntfsd] Retrieving security information regarding thread calling
IRP_MJ_C REATE>I think the following three Zw* calls should be enough to get
whatever you
>need:
>NTSYSAPI NTSTATUS NTAPI ZwOpenThreadToken(HANDLE Thread,
In processing MJ_CREATE, one must not use the thread’s current token - but
use the security context from the IRP.
There could be some filter driver above us that pend CREATEs to a worker
thread.
Max
—
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: xxxxx@ntpsoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com</mailto:xxxxx>