Applescript Sandboxing?

My app is an AppleScript GUI that uses Terminal to achieve the result of scripting Vagrant's execution of a VM, by means of running various shell scripts.


essentially it consists of various lines such as


tell application "Terminal"

do script ChangeToScriptDir & " && vagrant up && vagrant ssh -c 'cd /vagrant && somecommand ' ; vagrant suspend "

end tell


How do I get this to be compliant with sandboxing?

I could separate the various shell scripts into a separate component, but I cannot easily get round the requirement of running the shell scripts, in particular because they provide an incremental framework for constructing and updating the app.


E.

Replies

Which tools? OS X version....IDe environ, etc.

There no way to script Terminal from within the sandbox because that would let you easily bypass all of security that the sandbox provides.

You should be able to run your various scripts directly within your app. Whether that works will depend on what the scripts do. I'm not familiar with Vagrant but I suspect that it's going to want to do all sorts of things that are not compatible with the sandbox in order to bring up the VM. If that's the case, there's unlikely to be any good way to sandbox your app.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

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

KMT: I am developing on Yosemite 10.10. 4 with Script Editor 2.7, AppleScript 2.4, however I could use other tools if directed. I would like the app to be future and back compatible a bit.


Edmund

Quinn, D'you see any way for *my* Applescript app to script Terminal and still be compatible with Appstore rules?

Or should I just submit it and see what happens?

At the moment I have a solution for the user to run Vagrant to do some work in a Linux VM, which requires the users to launch Terminal and type, and this is what I'd like to automate and Gui-ize and sell on the Appstore. My app is a "helper". for people who need to use Vagrant for a special task.


Edmund

Scripting Terminal is not supported for Mac App Store apps because it would provide a trivial way to escape the App Sandbox.


--gc

As Quinn & others have indicated, the Mac App Store rules do not allow a scripting program to directly target any built-in application that has overly-broad access (including Finder, System Events, Terminal, etc.).


However, there is still hope, if not for a 'pure' AppleScript app then at least on the Cocoa / AppleScriptObjC side ... If the latter approach is indeed desirable / feasible, then note that OS X 10.8 introduced the interesting NSUserScriptTask class-family, which does allow running various types of scripts that target arbitrary applications, in a Sandboxed environment. Such scripts must be located within a special 'blessed' user folder; more specifically, your program's designated sub-folder within it, denoted by the 'NSApplicationScriptsDirectory' constant (which currently resolves to: ~/Library/Application Scripts/<your app's bundle-identifier>).


Your Cocoa / ASOC program does not have write access to that sub-folder, so in the typical scenario the user would [agree to] manually place scripts there. The key is that the user, not your program, remains in control of access to such 'blessed' scripts, including any of yours that s/he may install there. Since the scripts could be removed at any time, your program must also gracefully handle their absence (e.g., by re-prompting to install).


If your program also needs to obtain the results from such scripts, rather than just running them, then the various 'NSUser{AppleScript | Automator | Unix}Task' subclasses are tailored to do so respectively for AppleScript, Automator & Shell scripts.


From this perspective, for instance the NSUserAppleScriptTask subclass could be considered as the Sandbox-compliant edition of the older NSAppleScript class. There is one important behavioural change to remember, though; viz., NSUserAppleScriptTask's '- executeWithCompletionHandler:' method executes its associated AS script in asynchronous mode (which is why it uses a completion handler-block), so if you need to emulate synchronous execution instead then just use an appropriate thread-synchro mechanism (a lock, etc.).


[BTW, not really sure whether I'm allowed to say this in the forum, but there is a useful article on Sandbox-compliant scripting available at the 'www.objc.io' website: 'Scripting from a Sandbox' (Issue 14: Back to the Mac, July 2014).]


Best of luck,


--Paul