Running multiple instances of the same XPC service (NSXPCConnection)

Question

Is it possible to run multiple instances of the same XPC service using the XPC APIs found in Foundation.framework (NSXPCConnection, etc.)? The docs don't provide much insight on this matter.

EDIT: Did a quick test, and it seems like only one instance of the service is running even though I created two XPC connections. Is there any way to have it run another instance?

Contravention

Answer 1

I believe XPC services designed for one instance per multiple connections. Probably, it is more convenient to manage named pipes with one running executable. So, the most likely it is impossible to create multiple instances simultaneously.

Wilkens

Answer 2

A bit late, but the definitive answer to this question is provided in the xpcservice.plist manpage:

ServiceType (default: Application)

The type of the XPC Service specifies how the service is instantiated. The values are:

• Application: Each application will have a unique instance of this service.

• User: There is one instance of the service process created for each user.

• System: There is one instance of the service process for the whole system. System XPC Services are restricted to reside in system frameworks and must be owned by root.

Bottom line: In most cases there is a single instance of an XPC Service and only in the case where different applications can connect to the same service (not even possible when the service is bundled with an app), will there be multiple instances (one-instance-per-app).

Logrolling

Then how Safari and Chrome have multiple helpers. How they created? Even I need multiple helper Agents, any suggestion & help plz...#29681096 – Lambency

@AnoopVaidya I don't know the answer to that question. It's possible they are simply forked as children and Chrome isn't sandboxed. – Logrolling

Thanks for the reply, I achieved it though a console based applications....and the project is being used by thousands of users. – Lambency

Answer 3

Since XPC services should have no state, it should not matter, whether one ore more instances are running:

XPC services are managed by launchd, which launches them on demand, restarts them if they crash, and terminates them (by sending SIGKILL) when they are idle. This is transparent to the application using the service, except for the case of a service that crashes while processing a message that requires a response. In that case, the application can see that its XPC connection has become invalid until the service is restarted by launchd. Because an XPC service can be terminated suddenly at any time, it must be designed to hold on to minimal state—ideally, your service should be completely stateless, although this is not always possible.

–– Creating XPC Services

Put all neccessary state information into the xpc call and deliver it back to the client, if it has to persist.

Bicknell

It matters if the XPC Service uses a plug-in architecture to extend functionality and the app author wants to keep each invocation apart for security (and other) reasons. I, for one, am disappointed that multiple instances of an XPC Service cannot be defined. – Logrolling

How can a second instance improve security? – Bicknell

If the plug-in is written as a bundle (dynamic library) then it has access to the whole process. It's therefore better to keep plug-ins apart from each other in their own processes. – Logrolling

And if there is a second instance, there is a vector that does not work, but with a single instance? Can you show me an example? – Bicknell

I don't follow your question. – Logrolling

You said that it could be a advantage for security, if there is more than one instance of an XPC running. I cannot see any concrete example for an attack that does work, if you have a single shared instance, but does not work, if you have more than one instance. Can you show me an example? – Bicknell

No I cannot, however it's much easier to access the memory of the current process compared with the memory of another process. Other advantages of separate processes are for cases where you are using libraries that are inherently single-threaded or don't clean themselves up properly, leading to memory leaks. Having a single-process-per-"job" is much more convenient. – Logrolling

You cannot have two instances of /the same/ XPC. If it is malicious, a second instance would be malicious in the same way. If one can attack the first running instance, he can attack the second one. There is no advantage. – And for sure it is not the task of XPC to heal memory leaks in code your XPC uses. – If your XPC is stateless, requests running concurrently should be no problem. This is the advantage of being stateless. Maybe XPC is simply the wrong tool for you. – Bicknell

I am not talking about a bespoke hacking attempt of a process, but more a malicious plug-in which one of the sub-processes is running and not the other. It seems XPC would be perfect for me if there was a "one-instance-per-connection" option, however that is not the case, so an alternative must be found. – Logrolling

Answer 4

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/xpcservice.plist.5.html

ServiceType key in XPCService dictionary: Application or User or System

But this ‘ServiceType’ is irrelevant… IF Service is embedded in an application bundle then it will only be visible to the containing application and will be, by definition, Applicaton-type services. A subsequent connection request from an application to a service will result in a new connection to an existing service.

Dominions

Answer 5

I know I'm late to the party, but while you can't do this with plain XPC, there's library (a component of OpenEmu) that should be able to do what you're asking: OpenEmuXPCCommunicator

Abib