Communication between secondary apps and ES system extension

Question

Created Aug ’20

Replies 2

Boosts 0

Participants 2

I've read the following and tried to implement the fix in the following by adding the entitlement to the ES system extension, but I'm still having trouble getting multiple secondary apps to communicate with the ES system extension via XPC. Communication between the host app and system extension work just fine.

https://developer.apple.com/forums/thread/129551

Does this need to be added to all apps that need access? That seems like overkill.

I've also seen reference to several forum posts regarding the use of NSEndpointSecurityMachServiceName in the ES system extensions Info.plist file. I have yet to use this as I'm relying on the whole <teamid>.com.<org>.<productname>.xpc dance for now. Could this be related to the problem?

There are other forum posts that reference the app group in the provisioning profile. Does anyone have any insight there? Or is that something specific to NE?

Specifically, I have an authorization plugin and a preference pane that I would like to have communicate directly with the ES system extension so that I don't have to introduce another layer of XPC complexity such that it all has to be marshaled through the host app.

This is all signed with a Developer ID, so I'm not worried about distribution on the AppStore.

Thanks in advance.

Answered by DTS Engineer in 629199022

Does this need to be added to all apps that need access?

If you mean com.apple.security.temporary-exception.mach-lookup.global-name, that’s only necessary for sandboxed app. By default the App Sandbox prevents the app from touching arbitrary services outside of its sandbox.

Honestly, I think NSEndpointSecurityMachServiceName is the right answer here. It lets your ES sysex publish a global Mach service that any process on the system can connect to (unless blocked by the sandbox).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Aug ’20

Accepted Answer

Does this need to be added to all apps that need access?

If you mean com.apple.security.temporary-exception.mach-lookup.global-name, that’s only necessary for sandboxed app. By default the App Sandbox prevents the app from touching arbitrary services outside of its sandbox.

Honestly, I think NSEndpointSecurityMachServiceName is the right answer here. It lets your ES sysex publish a global Mach service that any process on the system can connect to (unless blocked by the sandbox).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 2

md4 OP

Aug ’20

Honestly, I think NSEndpointSecurityMachServiceName is the right answer here. It lets your ES sysex publish a global Mach service that any process on the system can connect to (unless blocked by the sandbox).

Is the value for NSEndpointSecurityMachServiceName allowed to be any arbitrary string or does it still need to conform to <teamid>.<bundleID>.xpc?

Testing shows that the following don't work when trying to make a connection between the sysex and the host app:

<bundleID>
<bundleID>.xpc
<teamid>.<bundleID>

On 10.15.6 (19G2021) and 11.0 Beta (20A5354i), man EndpointSecurity doesn't indicate that it has to be of a certain format, only that a default mach service name will be used:

NSEndpointSecurityMachServiceName
Type: String
If set, this string will be the name of the MachService which can be used for XPC between the ES
extension and its app. If ES extension is combined with a Network Extension, set the NEMachServi-
ceName key in the Info.plist. If not set, a default mach service (name: <teamID>.<bundleID>.xpc)
will be provided but its usage is deprecated.

I'm curious, for the record :)

Thanks in advance.

0