rfm@... wrote:

>Ok, i checked this out a little. First of all, to use IPC access,
>the server service must be run as localsystem, because it needs
>the 'interact with desktop' right, which only services running as
>localsystem are allowed to have. It doesn't actually need to interact
>with the desktop, but IPC is initiated by a windows message, so this
>right is required. There was talk of removing the use of windows
>messaging
>this in the next generation IPC protocol, so this issue might go away.
> I first tried taking away the 'interact with desktop'
>right (while continuing to let IB run as localsystem), and, as expected,
>I could connect with tcpip loopback but not with IPC. Anyway, I created
>an NT user interbase, with the default priviledges (a member of the
>group 'users' and nothing else), and set the server and gaurdian to run
>as that. Nt notified me that it had given the user interbase the 'log on
>as a service' right.

Fascinating. By IPC, I assume you mean using the local Interbase protocol.

A quick disassembly of the ibserver entrypoint for handling windows messages
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.

All Windows NT services get an invisible desktop on winsta0. Services which
do not run under .\System and services which do run under .\System, but do
not have the "interact with desktop" right cannot access winsta0\default,
which is the user's desktop. They still get an invisible desktop which
allows them to create windows, and send window messages.

Windows messages cannot cross desktops, so to use the local IB protocol the
server must run on the same desktop as the client applications. An
alternative, without changing the protocol, might be to call CreateDesktop
to create a new desktop purely for for IB messages, and create this with
appropriate permissions.

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 tried connecting with tcp/ip and failed. Checkin gthe interbase.log,
>there was a message saying that the gaurdian could not start the server.
>I then added the interbase user to the administrators group, (I know
>this
>defeats the purpose, but it helps the process of elimination), and
>was able to connect via tcp/ip. So this means its a matter of finding
>the right rights (or is that rites ? ;-)

>
>Final result (after a misguided attempt buring some old apple ][
>floppies while facing Redmond), was that setting the >gaurdian< to log
>on as local system, and the server to log on a regular user interbase
>(who did not have admin privs) allows a tcp/ip connection.

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.

Jan Mikkelsen
janm@...