Communication between running application and service [C++]

[Shaitan00]

Currently I have an application (A.exe) which determines when things need to be done, when such a time arises it launches another application (B.exe) with the appropriate parameters to do the actual work required, some of which could be administrative work (installing MSI, editing registry, etc...).

This all works perfectly fine in an administrative environment - but soon the application will be migrated to a restricted (user) account where the running application (A) does not have the rights to launch application (B) to the necessary work. The solution, have an administrative service (service installed when logged on as admin during software installation), and have this service communicate between (A.exe) and (B.exe)... Let's call the service (C) ...

My goal is therefore as follows:
- (A.exe) tells (C) that something needs to be done (somehow)
- (C) launches an instance of (B.exe) with admin rights (as it is an admin service) and (B.exe) performs the job just like it did before

Now this raises a few questions I was hoping to get some feedback on from people who have encountered similar situations or have advice they could give me so I don't shoot myself in the foot :)

1- My assumption is that I should be using C++ for my admin windows service, because C# requires all the managed DLLs and stuff I didn't want to risk any issues loading anything when running the admin service in a restricted user environment... am I crazy?

2- What would be the best method of communication between (A.exe) and the service (C), I need to take into account the difference in security (admin vs user), would using POST MESSAGES (windows or not) and have (A.exe) "find by name" work, could I get handle to (C) when I am user and it is admin? I would like to not use the registry or a file (like a mailslot) to communicate between them - but I am not sure what the best approach would be.

3- Will this actually work, if (C) launches (B.exe) does that imply that (B.exe) will have the admin rights it needs to perform its tasks?

Any help or hints would be much appreciated - trying to get a good & proper design in place before I start coding ... any ideas or lessons-learned you could provide would be great.
Thanks,

[wildgoose]

I personally like the idea (which I use) of a local IP port using a simple message protocol. Your Host Server App opens a listener port on a specified port # using the local IP 127.0.0.1
Your Client App's merely connect to it!

[Shaitan00]

Does this cause any issues when it is local (I assume you use the 127.x.x.x), also what about PORT? Do you need to change firewall settings (I don't have that kind of access) if it is local.

Will this work between a SERVICE and an APPLICATION?
Thanks,

[wildgoose]

You're behind the firewall. You're using a Local Host IP, which is specific only to that machine and not seen outside of it. That's why its a local IP such as 192.1.68.#.# makes it available outside that computer on the local network. If you use a global IP, it can be seen outside the firewall (as well as the Local IP) only if the firewall maps the global IP through, or remaps the real global IP to the local IP of that computer.

I'd recommend using an INI file. And use the Local Host IP: 127.0.0.1 as a default. that way if you wanted to, you can easily put both host and client on separate computers, still protected by the firewall. It also allows you to alter your port number for more flexibility. Especially if that port is used by another app.

[COMM]
IP= 127.0.0.1:3000

Service apps can create sockets at any time. Since you're on windows you could use pipes, but I like sockets since they're more portable between operating systems.

You can do the network in various ways. You can send from the client to the host without establishing a connection. You could also do a local multi-cast, or broadcast.

[Ancient Dragon]

This all works perfectly fine in an administrative environment - but soon the application will be migrated to a restricted (user) account where the running application (A) does not have the rights to launch application (B) to the necessary work. The solution, have an administrative service (service installed when logged on as admin during software installation), and have this service communicate between (A.exe) and (B.exe)... Let's call the service (C) ...

The solution is for the programs to call win32 api function LogonUser() so that they can inpersonate an Administrative account. I have done that may times and it works well. I stored the account name and encrypted password in the registry, then change that password frequently (such as weekly). The registry entry is initially created during program installation, which is run under an administrative account.

>>Since you're on windows you could use pipes,
Pipes don't work on MS-Windows programs.

If used in a Windows program, the _popen function returns an invalid file pointer that causes the program to stop responding indefinitely. _popen works properly in a console application. To create a Windows application that redirects input and output, see Creating a Child Process with Redirected Input and Output in the Windows SDK.

[Shaitan00]

I cannot use impersonation sadly - I am not privy to the ever changing Admin Account Passwords... and sometimes not even the user names ...

[Ancient Dragon]

In that case, sockets or COM would probably be best.