Subject | Re: [IB-Architect] Running as a normal user on NT. |
---|---|
Author | rfm@collectivecomputing.com |
Post date | 2000-04-27T01:30:35Z |
[...]
syncronization objects for communication between client and server.
However, the initial communication is started using a windows message.
(If i remember right, it's the initial communication of some
handle that is the problem.)
The reason it is this way is that the original work was for what was
supposed to be the successor to 16bit Local interbase on 95. (which has
no concept of window stations, services, security and so on). As work
on the LIBS '95 project continued, it was realized that
it basically had everthing the NT server did, and the same work
could be leveraged for the NT server (which was initially supposed
to be a different product). The initiation process was never
revised, because making the service 'interact with desktop' was
a workable solution. (Although it does mean that any OTHER services
which are interbase clients must either also interact
with the desktop, or communicate with loopback. This is a less
than ideal situation.)
[... interesting stuff snipped ...]
I suspect that the open process is so that the server will notice
when the client dies. (although I could be wrong).
[...]
--
Reed Mideke
rfm(at)collectivecomputing.com
>Yes
> Fascinating. By IPC, I assume you mean using the local Interbase protocol.
>
> A quick disassembly of the ibserver entrypoint for handling windows messagesThe current local access system uses a memory mapped file and
> shows that it handles WM_USER+1 and WM_USER+2. In response to 0x401, it
> calls OpenProcess with PROCESS_ALL_ACCESS, presumably based on the process
> ID it received with the message. I didn't check too closely.
>
syncronization objects for communication between client and server.
However, the initial communication is started using a windows message.
(If i remember right, it's the initial communication of some
handle that is the problem.)
The reason it is this way is that the original work was for what was
supposed to be the successor to 16bit Local interbase on 95. (which has
no concept of window stations, services, security and so on). As work
on the LIBS '95 project continued, it was realized that
it basically had everthing the NT server did, and the same work
could be leveraged for the NT server (which was initially supposed
to be a different product). The initiation process was never
revised, because making the service 'interact with desktop' was
a workable solution. (Although it does mean that any OTHER services
which are interbase clients must either also interact
with the desktop, or communicate with loopback. This is a less
than ideal situation.)
[... interesting stuff snipped ...]
> This doesn't solve the problem of OpenProcess(PROCESS_ALL_ACCESS, TRUE,???
> pid). It looks to me like the whole local access protocol should be
> revisited.
>
I suspect that the open process is so that the server will notice
when the client dies. (although I could be wrong).
[...]
>This is the conclusion that I came to as well.
> Guardian must run as LocalSystem because it needs to be able to restart the
> Interbase service. This requires privileges, and is acceptable because (I
> hope) Guardian doesn't talk much to the outside world.
>
--
Reed Mideke
rfm(at)collectivecomputing.com