Does the Sandbox stop a static library (linked into a Safari App Extension) from opening files from a Cocoa Resource Bundle (copied into that Safari App Extension)?

App architecture


I am making a macOS Safari (native) App Extension. It's hosted by a macOS Cocoa app.

The App Extension links a static library, and also copies in a Cocoa Resource Bundle.

Aim (and expected behaviour)


The static library needs to read from this resource bundle at runtime.

For a regular macOS app (not an App Extension) that has no entitlements file (and thus, no sandboxing), I find that this file access works just fine.

The file access also works on iOS, for an app that has been accepted into the App Store. Of note, the iOS app doesn't list any Sandbox-related entitlements.

Observed behaviour


For the App Extension, when the static library tries to access the resource bundle at runtime, I receive an error upon file access.

I have no error message to share, unfortunately (I haven't worked out how to pass the error message up from the low-level C++ code in the library to the Obj-C code that abstracts it). I'll try to produce one if this issue doesn't indeed smell like a Sandbox issue, though C++ is foreign to me.

So is this definitely a Sandbox issue? Can I rule that out somehow whilst still being able to install the App Extension into Safari to test it? And if it is a Sandbox issue, is there any way I can give the static library access to the resource bundle whilst satisfying the Sandbox?

This is an initial writeup to see if the failure pattern rings any bells – I'm happy to provide an infinitely deeper level of detail if anything more needs probing.
Answered by DTS Engineer in 618309022
The sandbox will always allow an app (or appex) read-only access to its own bundle. I’m not sure what’s going on here, but it seems unlikely that it’s a sandbox issue. I think you should dig into the code doing the access to make sure it’s calculating file URLs/paths correctly. That’s easy to mess up in a situation like this.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Is the bundle nested inside the .appex?

Share and Enjoy

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

Is the bundle nested inside the .appex?

@eskimo Yes, both the static library and the Cocoa Resource bundle are nested inside the .appex.
Accepted Answer
The sandbox will always allow an app (or appex) read-only access to its own bundle. I’m not sure what’s going on here, but it seems unlikely that it’s a sandbox issue. I think you should dig into the code doing the access to make sure it’s calculating file URLs/paths correctly. That’s easy to mess up in a situation like this.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Got to the bottom of it using opensnoop. Whoever had written the static library had built their own custom CLI argument parser that simply split arguments on whitespace without taking note of string quotes or escape characters, and my App Extension had a space in its name so it ended up asking to read a resource from a path that involved a space... and went off looking for a file outside of the container’s file system due to the broken filepath.

So indeed it wasn’t a Sandbox issue after all. Thanks!
Does the Sandbox stop a static library (linked into a Safari App Extension) from opening files from a Cocoa Resource Bundle (copied into that Safari App Extension)?
 
 
Q