A customer was running into this problem with a shell extension:
I am writing a shell namespace extension. I need to get data from a COM server, which requires impersonation via
RPC_C_IMP_LEVEL_IMPERSONATE. As I am just writing an extension into
explorer.exe, I am not able to call
CoInitializeSecurityanymore from my extension. Is there a way I can start
RPC_C_IMP_LEVEL_IMPERSONATEin its COM initialization? I was browsing through web, and
explorer.exeseems to take some settings from registry, but couldn't find anything related to this one.
First of all, who says that the host process is
explorer.exe? If I open Notepad, then do a File.Open, and then navigate to your shell extension, boom, your shell extension is now loaded into Notepad, and I doubt you told Notepad that you wanted it to initialize COM in a special way, just for you. Same goes for Quicken, Lotus Notes, all those other programs that use the shell. Even if you solved the problem for Explorer, that doesn't solve your problem in general.
Second, what if two shell extensions did this? Your shell extension requires
RPC_C_IMP_LEVEL_IMPERSONATE, but another one requires
RPC_C_IMP_LEVEL_DELEGATE. Who wins? Or are those shell extensions mutually incompatible? And what about the effect your decision has on the other shell extensions hosted by Explorer? Now they are running with
RPC_C_IMP_LEVEL_IMPERSONATE even though they didn't ask for it. Will that introduce a security vulnerability? Will those other shell extensions stop working or even crash?
A shell extension is a guest in the host process's house. You don't go and change the color of the carpet when you are invited over for dinner.
This question is yet another example of using a global setting to solve a local problem. To solve your local problem (I need this specific COM interface to run with impersonation), use a local solution.