Sandboxing a Command Line Tool With Paths As Arguments
In order to get access to random files outside of the app container, you can ask the user to select a folder using an Open dialog. The app will then be allowed to access any file inside this selected folder… as long as the app is running. If the app is quit and relaunched (as you might expect from a command line tool), you will need to use Security-Scoped Bookmarks to keep this access persistent.
[…]
It all sounds simple… until you realize that a command line tool can’t prompt the user to select a folder using an Open dialog. The solution I came up with, is to prompt the user in the main app and pass the Security-Scoped Bookmark to the command line, easy right?
[…]
The main app can pass non-secure bookmark to a child process. How does it help in our case where the command line tool is not a child process? Well it turns out that the main app can pass the non-secure bookmark to the command line tool as long as both binaries are running at the same time.
This is a mess. It seems like command-line tools shouldn’t need to be sandboxed. If I’m invoking the tool from Terminal, it should have whatever access my current Terminal window does. Likewise, if the containing app invokes the tool, it would be limited to what that sandboxed app can do. I’ve seen conflicting reports on what the rules are, perhaps because App Review has been inconsistent in what it approves.
See also: Using non-sandboxed XPC service from Sandboxed app extension.
Previously:
- Kaleidoscope 3.6
- Mac APIs that Require Provisioning Profiles
- Adding a Command Line Tool Helper to a Mac App Store App
- Sandbox Limitation on Number of Files That Can Be Opened
Update (2024-03-05): Nick Lockwood:
Suppose I have a Mac App Store app with an associated command line tool.
I don’t want to embed the tool in the app itself, but instead make it available via a download link. What would be a good, App Store compliant way to make that available to the user?
