Re: Calling cocreateinstance from an impersonated thread
- From: "Brian Muth" <bmuth@xxxxxxxx>
- Date: Wed, 21 Nov 2007 08:23:06 -0800
<sujilsekhar@xxxxxxxxx> wrote in message news:896af451-7a86-4bec-9b76-7ec52418e6e4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I am facing one issue with the user context where com objects get
loaded. My program flow is as follows
1. I have two inproc com components say Comp1, Comp2
2. My client is an executable running in SYSTEM context
3. Client loads comp1 and is running in SYSTEM context
4. comp1 is creating a thread inside and this thread got impersonated
to a particular user context
5. This impersonated thread calls comp2 using cocreateinstance
6. My requirement is to load the comp2 in the impersonated context but
the cocreateinstance
takes the process token instead of impersonated token.
In various posts i read that for outproc servers you can overcome this
by setting security blankets. But this method is not working for
inproc severs.
CoSetSecurityBlanket is only for out-of-proc DCOM servers, and cannot work for inproc DLL's.
The only way I can see this working is to ensure that comp2 runs in the same apartment as the calling thread. The impersonated thread then can enter comp2 directly, and the security context is preserved.
HTH
Brian
.
- References:
- Calling cocreateinstance from an impersonated thread
- From: sujilsekhar
- Calling cocreateinstance from an impersonated thread
- Prev by Date: Calling cocreateinstance from an impersonated thread
- Next by Date: Re: shared memory + IStorage
- Previous by thread: Calling cocreateinstance from an impersonated thread
- Index(es):
Relevant Pages
|
