My cocoa app design is a single .app (the UI) and three XPC services.
The main app needs file read-only to show the powerbox and display the selected path in the UI
- com.apple.security.app-sandbox
- com.apple.security.files.bookmarks.app-scope
- com.apple.security.files.user-selected.read-only
Two of the XPC services need file read-only
- com.apple.security.app-sandbox
- com.apple.security.files.bookmarks.app-scope
- com.apple.security.files.user-selected.read-only
One XPC service needs file read-write
- com.apple.security.app-sandbox
- com.apple.security.files.bookmarks.app-scope
- com.apple.security.files.user-selected.read-write
Due to the flow of the user interaction, the main app opens a powerbox dialog to allow the user to select a directory and display it in the UI. The main app then saves this as a security scoped bookmark. The bookmark data is sent across the XPC connections as needed and each separate XPC process resolves the bookmarks to gain access to those files in its own sandbox.
The problem is, unless I set the main app (which opens the powerbox) to have file read-write access, the XPC service that needs write access won't get it even though its entitlements file specifies file read-write access. The following is logged in the console:
deny file-write-unlink <file path>
Is the only way around this to give the main app that opens the powerbox file read-write entitlements, or redesign the UI flow so the process needing write access displays the powerbox? The end goal is to have each process have as few permissions as possible. The ideal entitlements would be to have no file-access in main .app process, two XPC services with file read-only and one XPC service file read-write. Thanks!
Edit:
Powerbox and File System Access Outside of Your Container :
The OS X security technology that interacts with the user to expand your sandbox is called Powerbox. Powerbox has no API. Your app uses Powerbox transparently when you use the NSOpenPanel and NSSavePanel classes.
I’m not an expert in the sandbox, but, hey, not even the guys who wrote it are. Zing!
Anyhow, it makes sense architecturally for embedded XPC services to only be allowed a subset of the containing app, if that’s indeed what’s happening. An argument could be made against it, but the argument for would be that it’s a lot easier for the system and users to understand what an application might do if it has to declare EVERYTHING at the top level, and lower levels (XPCs) are only allowed to do as much or less.
While it’s admirable to try to keep your entitlements as small as possible, in this case you really are opening a file for reading and writing, so you might as well declare it.