From: Le Chaud Lapin on 20 Apr 2010 15:06 Hi All, I have what might be a common problem. [Note that I never bother to study in any detail the Windows security model, so my terminology, perception, etc. might be incorrect.] In my distributed system, I normally have an application, Client.exe, that must talk to Server.exe, via named shared memory. There is a one-to-one correlation between "users" on a Windows machine and Client.exe/Server.exe pairs. For 7 logged-in users, there would be 7 pairs. My shared memory, and all other named kernel objects, are created with the omission of "\\global", so as to take advantage of automatic disambiguation provided by the kernel naming model. It turns out that, in some cases, Client.exe is actually Client.dll, an ISAPI DLL. My goal is to find the technically correct method for having Client.dll talk to Server.exe while taking into account the potential plurality of logins and web servers running on the same machine. Obviously, running Server.exe under a normal login while letting ISAPI load Client.DLL will cause Client.dll to reference objects in the kernel space different from those referenced by Server.exe. My guess is that adding some code into Client.dll to launch Server.exe via CreateProcess from Clien.dll will, at least, allow Client.DLL to share same namespace as Server.exe. Questions: 1. Will the CreateProcess method work? 2. If so, is there a command line launch opportunity from within the context of Client.DLL? I would rather not put code in Client.DLL just to launch the companion Server.exe. 3. What login/account/security/etc. model do hosting providers use to allow, say, 10 customers to share one IIS instance? What happens when each of 10 web sites uses an ISAPI DLL to invoke CreateMutex("SomeName")? What elements will I have to allow disambiguation? TIA, -Le Chaud Lapin-
|
Pages: 1 Prev: NetBIOS error when using shared config Next: Cant make ISAPI_filter work (or even break) IIS7 |