Hello,
I'm running into an issue with a complex macOS application (non-AppStore) structure involving an unsandboxed system daemon and a sandboxed SSO Extension attempting to communicate via XPC Mach service.
The macOS app is composed of three main components:
- Main App: unsandboxed, standard macOS application.
- System Daemon: unsandboxed executable installed with a .plist to /Library/LaunchDaemons/ and loaded by launchd. It exposes an XPC Mach Service.
- SSO Extension: a sandboxed Authentication Services Extension (ASAuthorizationProviderExtension).
Main App to System Daemon communication works perfectly. The unsandboxed main app can successfully create and use an XPC connection to the System Daemon's Mach service.
But SSO Extension cannot establish an XPC connection to the System Daemon's Mach service, despite using the recommended temporary exception entitlement. I have added the following entitlement to the SSO Extension's entitlements file:
<key>com.apple.security.temporary-exception.mach-lookup.global-name</key>
<array>
<string>my.xpc.service.system.daemon</string>
</array>
(The name my.xpc.service.system.daemon is the exact name registered by the System Daemon in its Launch Daemon plist's MachServices dictionary.)
When the SSO Extension attempts to create the connection, the following log output is generated:
default 08:11:58.531567-0700 SSOExtension [0x13f19b090] activating connection: mach=true listener=false peer=false name=my.xpc.service.system.daemon
default 08:11:58.532150-0700 smd [0xb100d8140] activating connection: mach=false listener=false peer=true name=com.apple.xpc.smd.peer[1575].0xb100d8140
error 08:11:58.532613-0700 smd Item real path failed. Maybe the item has been deleted? <private>
error 08:11:58.532711-0700 SSOExtension Unable to find service status (<private>) error: 22
The error Unable to find service status (<private>) error: 22. Error code 22 typically translates to EINVAL (Invalid argument), but in this context, it seems related to the system's ability to find and activate the service for the sandboxed process.
Questions:
Is the com.apple.security.temporary-exception.mach-lookup.global-name entitlement sufficient for a sandboxed SSO Extension to look up a system-wide Launch Daemon Mach service, or are there additional restrictions or required entitlements for extensions?
The smd log output Item real path failed. Maybe the item has been deleted? <private> seems concerning. Since the unsandboxed main app can connect, this suggests the service is running and registered. Could this error indicate a sandbox permission issue preventing smd from verifying the path for the sandboxed process?
Are there specific sandboxing requirements for Mach service names when communicating from an Extension versus a main application?
Any guidance on how a sandboxed SSO Extension can reliably connect to an unsandboxed, non-app-group-related system daemon via XPC Mach service would be greatly appreciated!
My general advice on this front is to avoid temporary exception entitlements where you can. This is critical for App Store apps, but generally a good idea for products that you directly distribute using Developer ID signing.
In this case there’s a standard way for sandboxed programs to use XPC without needing temporary exception entitlements, namely an app group. If you set up an app group, grant your app and your appex access to that group, and then have your daemon publish its named XPC endpoint ‘within’ that group, the sandboxed processes should be able to access that service without the need for a temporary exception entitlement. See App Groups Entitlement for info on how that works.
Well, the app certainly will be able to. The situation with the appex is more nuanced, because appexen run in a custom sandbox that doesn’t always align with the standard App Sandbox used by apps. Which is probably the reason why your temporary exception entitlement is failing. I think the app group approach will help here, but I’m not in a position to test that today.
Oh, and app groups on the Mac have a bunch of subtleties. See App Groups: macOS vs iOS: Working Towards Harmony for the backstory.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"