A customer said that they had two applications running on the machine. The client application is running non-elevated, and the service application is running elevated. They want the client to be able to make calls into the service without making the user approve elevation prompts for each call.
They tried playing around with various flavors of CoÂCreateÂInstance, but they always ended up with an elevation prompt or a non-elevated server.
I double-checked that when they said that they had a “service application”, they meant that they had a classic Windows service.
It was, and the answer has been around for decades.
Create an RPC service endpoint and set the service to start on demand. As an additional protection, you can use ACLs to control who can access the service (if you want to limit it to specific users or groups). But you still must handle the case where the client has been compromised. There is sample code on MSDN showing how to do this.
The customer confirmed that the tutorial worked as advertised and meets their needs. In fact, they realized that the service would already be running at the time the client needed to connect to it, so they didn’t actually need the auto-start functionality, but it was nice to know that it was available.
Larry Osterman noted that another solution is to register their COM server with an AppID that specifies that it should run in a service. In that case, COM will auto-start the service when the COM object is created.
The approach I’ve used with this problem before (non-elevated UI process running in session and elevated service running in session 0) is to have the service host a named pipe and the client connect to it to send commands to perform operations.
I would have just use the “sc control” way to send a number if it’s simple action to invoke (like a sync task without need of custom parameter), or go the *nix way to use UdpClient if the task would need more information to run.
The argument runs like this...
If you choose to use named pipes, you're responsible for whatever connects on that pipe and sends you data - valid or not.
If you choose to use RPC / COM, Microsoft is at least taking care of the marshalling / message packing / unpacking for you, and likely a good chunk of the security as well in many cases. If there's a bug there (which tends to be...
The argument against COM in my book is that it’s ungodly complicated to correctly use and set up so the chances that you introduce bugs there are much higher than if you use some standard serialization library and put ACLs on your named pipe (which you have to do for the COM solution too).
In my experience, running into a bug in a 3rd party component or service is not a good place to be. It doesn't win you much sympathy with your customers (who just want your product to work!) and you are more limited in your options to resolve it.
It may be an urgent issue for you, but not for the 3rd party vendor. It does get fixed without you doing anything, but not on your terms...
For more loosely coupled interactions, MSMQ is another traditional means of connection. We’ve done that when the non-privileged side is triggering mostly “fire and forget” requests for action to the elevated worker.