I've discovered that a system network extension can communicate with a LaunchDaemon (loaded using SMAppService) over XPC, provided that the XPC service name begins with the team ID.
If I move the launchd daemon plist to Contents/Library/LaunchAgents and swap the SMAppService.daemon calls to SMAppService.agent calls, and remove the .privileged option to NSXPCConnection, the system extension receives "Couldn't communicate with a helper application" as an error when trying to reach the LaunchAgent advertised service. Is this limitation by design?
I imagine it is, but wanted to check before I spent any more time on it.
Is this limitation by design?
Yes. An launchd agent runs in user context [1]. A system extension is like a launchd daemon, which runs in the global context. Code running in the global context can’t communicate with code running in a user context because:
- There can be multiple user contexts, so it’s not clear which one you’d end up talking to.
- There may be no user contexts.
In contrast, code running the same context can communicate [2], which is why your sysex is able to connect to your launchd daemon.
I discuss this in much detail in TN2083 Daemons and Agents. If you’re working at this level of the system, you need to read that and follow the rules it outlines.
Keep in mind that your sysex is pretty much a launchd daemon, so there may be no need to have a launchd daemon at all. You should be able to put all of its functionality in your sysex.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] The exact context is controlled by the LimitLoadToSessionType property.
[2] Modulo sandbox restrictions.