Open files in a Sandboxed command-line app

Question

Created Aug ’15

Replies 4

Boosts 0

Views 7.6k

Participants 2

I'm now trying to Sandbox my document-based application. The application bundles a helper command-line executable in `Application.app/Contents/MacOS/` to let users open their files easier in my application via command-line. So far, to sandbox the application itself has successfully been done. However, when I sandbox the helper command-line executable, or when I bundle the executable to the sandboxed application, files can not be opened in the application any more.

I use the following method to open files via command-line.

The main application is scriptable.
command-line executable uses ScriptingBridge to communicate with the main application
When the command-line executable launched, it creates a SBApplication instance with the main application's bundle identifier, and let it open file URLs that were given via command-line argument.

I've also made a minimum sample project in GitHub on the following URL to show how it works. The issue is reproduced also in this sample application.

https://github.com/1024jp/CommandLineBundleSample

Well actually, it seems that this problem is not based on the communication between sandboxed applications but because there is no way to open files passed as command arguments, namely as normal strings.

Question:

So, my question is; Is there any way to open a file of which path was passed as an argument to a Sandboxed command-line application? Or should I give up to bundle the command-line tool and release it out of the Mac App Store separately?

If there is any other way to reach the goal besides ScriptingBridge (e.g. XPC service, Application Group, etc.), it's also welcome to suggest.

Boost

Answer 1

DTS Engineer OP

Apple

Aug ’15

The main application is scriptable.

Temporarily ignoring your command line tool for the moment, what happens when you open the document via AppleScript? Does that work?

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 2

1024jp OP

Aug ’15

Yes.

The following code for the sample project, for example, works correctly on Script Editor.app

set thePath to ((path todesktop folder) & "test.txt") as text


tell application "CommandLineBundleSample" to open file thePath

0

Answer 3

DTS Engineer OP

Apple

Aug ’15

Accepted Answer

I don't think there's a straightforward solution to this problem. The issue is that:

Mac App Store requires that every piece of code within your app be code signed and sandboxed, including your helper tool.
The App Sandbox is, as the name suggests, an app sandbox. So there's no affordance for sandboxing a tool independently of its parent app. Specifically, while you can sandbox a tool, there's no magic that gives the tool access to the paths that are passed to it via command line arguments.
Sandbox inheritance (
```
com.apple.security.inherit
```
), which is the way I generally recommend that folks sandbox their tools, does not work for this because Terminal is not sandboxed so, when you run the tool from the command line, there's nothing to inherit from.

You may be able to resolve the problem by converting your tool to some sort of script (a shell script, Python, whatever). That's almost certainly feasible from a technical perspective, I just don't know how it interacts with the Mac App Store rules. If no one else chimes in, I recommend that you open a DTS tech support incident and one of my colleagues will help you on a more formal basis.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 4

1024jp OP

Aug ’15

Ah, script. I didn't think about that. All right, I just wanted to conform if it is impossible or not. Your answer made my mind clear. I'll try using normal script file and I'll ask in the tech support incident if some other issue rises up. Thanks a lot.

0