/var/root/Library/Containers/ - no such file or directory

Hi,

We have a macOS app that starts the system network extension to provide the VPN service. I'm integrating the Crashpad to report crashes from the system network extension. To handle and report the crashes, in the network extension, we start the crash handler in a separate process and it listens to the Mach port for EXC_CRASH exceptions.

The crash handler needs to access the file system to create crash reports database. But I'm getting the "Applications Support" directory from the network extension, but the path is not found. Here's the error:

execvp /var/root/Library/Containers/<bundle ID>/Data/Library/Application Support/Crash/handler_mac: No such file or directory

That looks like a sandboxed app, running as root, expecting some app to be installed in root's home directory. You'll need to find a more stable way to locate the executable.

Just to be clear, I strongly recommend against using your own crash reporter. For the gory details as to why, see Implementing Your Own Crash Reporter.

But I'm getting the "Applications Support" directory from the network extension, but the path is not found.

OK. That path makes sense to me. Your NE sysex is run as root but is also sandboxed, so the sandbox container is hung off ~root. The fact that some item within your container is missing is not, in and of itself, a problem. Do you have code to populate that directory? If so, did it fail? And what was the error? If not, the directory will be empty, or possibly missing. That’s kinda how sandboxed containers work.

Share and Enjoy

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

I'm now setting sandbox to be false for both the containing app and the system network extension. And I'm getting the group container URL from and app and passing it into the network extension.

This is the group container URL I used: /Users/<user_name>/Library/Group%20Containers/<group_id>/Crash/

Question: Is there any concern regarding disabling the sandbox for the app and the system network extension? We are not distributing the app in the App Store.

Is there any concern regarding disabling the sandbox for the … system network extension?

Yes. NE providers must be sandboxed, and that includes both appex and sysex variants.

We are not distributing the app in the App Store.

In that case you should feel free to make liberal use of temporary exception entitlements.

IMPORTANT These entitlements are temporary in the sense that they were a stepping stone on the path to sandboxing for the benefit of the App Store. We don’t plan to remove them. If you’re not targeting the App Store, they are as solid as any other API on our platforms.

One day we’ll update the docs to make that clear (r. 90755718).

Share and Enjoy

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

Thanks for the suggestion on the temporary exception entitlements! I tried to add the following entry into the network extension's entitlements file:

 <key>com.apple.security.app-sandbox</key>
 <true/>
 <key>com.apple.security.temporary-exception.files.home-relative-path.read-write</key>
 <array>
 <string>/Library/Application Support</string>
 </array>

But I still couldn't read or write to the directory from the network extension process. This is the error I got:

mkdir /Users/<user_name>/Library/Application Support/Crash/: Operation not permitted (1)

There are a couple of issues here:

  • For the entitlement to cover the full directory hierarchy, you need to end the path with /.

  • You have a home-directory relative reference, but which user’s home directory are you referring to? Remember that your daemon is running as root.

Share and Enjoy

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

/var/root/Library/Containers/ - no such file or directory
 
 
Q