Prev: SEH not working with new stack (stack swapping)
Next: _chdrive / SetCurrentDirectory resetting the current directory on other drives?
From: Le Chaud Lapin on 28 Apr 2010 01:19
Hi All,

[This is repost from an IIS newsgroup since no response was received
there. Again, while I do research in distributed systems, access
control models, etc., I have never taken the time to study that of
Window's, which occasionally I regret. As such, even a terse answer
will be appreciated.]

In my distributed system, I normally have an application, Client.exe,
that must talk to Server.exe, via named
shared memory.

In my system, there is a one-to-one correlation between a "user" on a
Windows machine and a Client.exe/Server.exe pair. For example, for 7
logged-in users, there would be 7 client.exe/server.exe 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
running as an ISAPI DLL.

My goal is to find the technically correct/clean 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. Think
large hosting company with web farm with 10 customers per physical
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 if
Server.exe is not launched in context of Client.exe's account [this is
where I get lost].

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 that can be exploited under IIS? 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?
4. What happens when each of 10 web sites uses an ISAPI DLL to invoke
CreateMutex("SomeName")? What elements will I have to allow
disambiguation? I've seen things like SID/Group/etc.

TIA,

-Le Chaud Lapin-
From: Leo Davidson on 28 Apr 2010 04:47
On Apr 28, 6:19 am, Le Chaud Lapin <jaibudu...(a)gmail.com> wrote:

> In my system, there is a one-to-one correlation between a "user" on a
> Windows machine and a Client.exe/Server.exe pair. For example, for 7
> logged-in users, there would be 7 client.exe/server.exe pairs.

Have you considered making the Server.exe a "SingleUse" COM server?

You can write one of those and let COM take care of starting &
stopping each Server.exe instance for you. For each user, a Client.
(exe|dll) would create a single instance of the server's interface/
class and then hold on to and use that interface reference whenever it
needs to talk to the server. By default, COM will start the server in
the same context as the client code. (But you can change it to run
under different accounts if needed.)

From a quick search, (some versions of?) VB seem to have explicit
support for writing SingleUse COM servers (set "Instancing" to
"SingleUse" in the project somewhere). Can't say I've ever used it
though. If you're using something like C++, have a look at the
REGCLS_SINGLEUSE argument you can pass to CoRegisterClassObject.

I don't know how the ISS stuff works so can't help there.
From: Le Chaud Lapin on 1 May 2010 11:11
On Apr 28, 3:47 am, Leo Davidson <leonudeldavid...(a)googlemail.com>
wrote:
> On Apr 28, 6:19 am, Le Chaud Lapin <jaibudu...(a)gmail.com> wrote:
>
> > In my system, there is a one-to-one correlation between a "user" on a
> > Windows machine and a Client.exe/Server.exe pair. For example, for 7
> > logged-in users, there would be 7 client.exe/server.exe pairs.
>
> Have you considered making the Server.exe a "SingleUse" COM server?
>
> You can write one of those and let COM take care of starting &
> stopping each Server.exe instance for you. For each user, a Client.
> (exe|dll) would create a single instance of the server's interface/
> class and then hold on to and use that interface reference whenever it
> needs to talk to the server. By default, COM will start the server in
> the same context as the client code. (But you can change it to run
> under different accounts if needed.)

This last part.."By default, COM will start the server in the same
context" is most intriguing.

The problem is that I do not have a clear understanding of the
primitives for contextual separation in Windows:

1. user
2. login
3. SID
4. session
5. Window station
6. etc.

I have strong suspicion that, whatever COM does to start a server in
same context as client code, I could do the same thing myself, using
something like CreateProcessAsUser. The problem is that I don't know
what to write because I do not understand the model. Where can I find
a concise summary of what these things are? MSDN?

Thanks for your response,

-Le Chaud Lapin-
From: Leo Davidson on 2 May 2010 05:32
On May 1, 4:11 pm, Le Chaud Lapin <jaibudu...(a)gmail.com> wrote:


> I have strong suspicion that, whatever COM does to start a server in
> same context as client code, I could do the same thing myself, using
> something like CreateProcessAsUser.

You don't need to do anything special to start a process in the same
context as the code that is starting it. Just use CreateProcess.
Things inherit the existing context by default and you only have to do
complex things if you want to start a process as a different user.

What I can't say is whether or not your client code is running in the
context you want your server code to run in. I don't know enough about
ISS or what you're doing to answer that, sorry.
 | 
Pages: 1
Prev: SEH not working with new stack (stack swapping)
Next: _chdrive / SetCurrentDirectory resetting the current directory on other drives?