Using non-sandboxed XPC service from Sandboxed app extension

My scenario is to develop an app extension for a hardened-only (not sandboxed) application of mine.

This application cannot be sandboxed because it needs to execute shell commands (pdflatex, bash...), or more generally a user-deployed TeX environment.

The "app extension" is a feature I would like to add to my application. But to make it work, the "app extension" must be sandboxed, which is a problem, since there is no entitlement to allow the execution of scripts outside of the sandbox.

So I have a hardened application, hosting a sandboxed "app extension" which currently cannot perform useful work.

My idea was to call an XPC service from the App extension, that XPC service being non-sandboxed, hosted by the same (hardened-only, non sandboxed) application hosting the App extension.

I could succesfully build that, but it does not work.

When I call the service from the hosting app, the XPC service is correctly launched on demand, and perfoms correctly.
When I call the service from the app extension, the XPC service is not even launched, the remote proxy method call is a no-op (but strangely , no errors are raised, neither when connecting to the service, nor when trying to execute the remote method).

I wonder if I misunderstood the way to use XPC to "escape the sandbox". I am doomed, or is there a correct procedure to ultimately call an *external* pdflatex from an app extension ?
Answered by chacha21 in 639127022
As you suggested, I have moved the XPC service to embedd it inside the sandboxed App Extension rather than inside the hardened-only hosting application.
It seems to work : the sandboxed app extension can call the hardened-only service, which can call pdflatex on the shell.
I though that embedding the XPC service inside the sandboxed app extension would somehow sandbox the service itself, but it seems not to be the case.

As far as I understand : fixed.

I could succesfully build that, but it does not work.

Indeed. There’s actually two issues in play here:
  • XPC Services bundled within your app are registered in an app-specific namespace and thus aren’t visible to related code, like app extensions.

  • The App Sandbox will prevent your app extension from connecting to arbitrary XPC services.

You can work around the second issue using a temporary entitlement. There isn’t a general-purpose way to work around the first issue. However, in your specific case you could embed your XPC Service within your app extension. The XPC Service would then be registered in its namespace.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Accepted Answer
As you suggested, I have moved the XPC service to embedd it inside the sandboxed App Extension rather than inside the hardened-only hosting application.
It seems to work : the sandboxed app extension can call the hardened-only service, which can call pdflatex on the shell.
I though that embedding the XPC service inside the sandboxed app extension would somehow sandbox the service itself, but it seems not to be the case.

As far as I understand : fixed.
Using non-sandboxed XPC service from Sandboxed app extension
 
 
Q