Sandboxing enhancement - examining an application's context

Originator:samdeane
Number:rdar://9935732 Date Originated:11-Aug-2011 11:36 AM
Status:Open Resolved:
Product:Mac OS X Product Version:10.7
Classification:Enhancement Reproducible:Not Applicable
 
I have a utility application (Neu), currently on sale in the MAS, which is going to run into major problems with sandboxing as it currently stands.

The utility allows the user to create files quickly from templates. Really it just does a glorified copy of a stationery file into a location of the user's choosing - but it presents the user with a simplified interface for doing this.

The problem with sandboxing comes with how the utility chooses *where* to create the new file.

Initially Neu was written to be triggered by a Services menu selected from the Finder. It would then create the new file in the location represented by the Finder window that the user had open when they opened the services menu.

I am concerned that this may not work under sandboxing - unless the sandbox system automatically adds any paths that it supplies to an application to the list of allowed accesses.

However, there is a more serious problem. The Finder/Services integration isn't brilliant, and in particular, there's no way to right-click on a Finder window and have it show a services menu for the folder that the window represents (see rdar:7719410).

Because of this, I've added some other mechanisms for triggering Neu. These mechanisms rely on looking at the front window of the Finder, and inferring the location that the user wants to create files in from it. 

I'm assuming that this isn't going to work with sandboxing. Instead I'm going to have to throw up a "Save As" dialog and ask the user where to save the new file. This is already an option in Neu, but requiring it is going to annoy the users that turn it off by default.

It seems like sandboxing is a great idea, but if we're not careful it is going to destroy a whole class of utilities which work by integrating with other applications. The Finder is the most obvious of these other applications, but I'm sure that there are many additional examples - for example utilities that watch what track is being played in iTunes, and then do something with it.

Because of this, I think we need the possibility of specifying an entitlement allowing the application to interact with another process id - in a way that then allows the application to do the sorts of things that I've described.

In the case of Neu, right now I'd have to request permission to interact with the Finder. However, in future versions I was also planning to allow Neu to infer a save location from the currently open document in the front application - thus letting it integrate more intelligently with whatever program the user is currently using. This would require yet-more flexible permissions.

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!