I recently began implementing Mac App Store sandboxing (ugh) and noticed that saved HTML archives loaded into a WebView do not render referenced resources. For example, a saved webpage, MyPage.html, can reference styles.css, image.jpg, and script.js in a corresponding MyPage_files folder (Google Chrome's save "Webpage, Complete" convention):
MyPage.html
MyPage_files/styles.css
MyPage_files/image.jpg
MyPage_files/script.js
However, after loading the MyPage.html file into a WebView, the Console.app reports errors like this:
sandboxd: deny file-read-data /Users/user/Desktop/MyPage_files/styles.css
sandboxd: deny file-read-data /Users/user/Desktop/MyPage_files/image.jpg
sandboxd: deny file-read-data /Users/user/Desktop/MyPage_files/script.js
Should this be considered a bug, or is it something that is just a limitation of WebViews within the sandbox?
This is a limitation of the original sandbox design, but it's one that Apple has (at least partially) fixed.
Apple engineers have discussed the new solution in at least two places, but unfortunately, I believe they're both "prerelease" information sources that nobody outside of Apple is allowed to talk about in public places like this.
If you have a paid Mac Developer Program membership, go to the Application Sandboxing forum.
I believe "The OS X App Sandbox" video from The WWDC 2012 videos is available without a paid Mac Developer Program membership.
Also, keep in mind that you will need some kind of fallback, unless you're willing to require all of your users to upgrade to a new version of OS X. You should definitely file a bug with Apple explaining what you need, and post about it on the forums. You can post about it on the non-prerelease forums, because you're asking how to do this on Lion, which doesn't involve any confidential information.
One last point: if you're creating the archives yourself, you can save them so that there's a MyPage bundle with the .html file and _files subdirectory inside it; then, when the user selects your bundle, you'll have access to everything. But of course this won't work if you're trying to open, e.g., archives created by Safari.
Related
I have a Mac desktop application developed using Xamarin.Mac and XCode. The application is loading views that should have a considerable amount of content as blank/white screens for a select few end users. While I've not been able to reproduce the issue locally and it doesn't appear to be impacting many people, it does happen consistently for a handful of users(6 out of over 4,000 at the moment). The app works just fine for the vast majority and uses a main window controller that sets the content view as needed by calling the applicable ViewController. When the views in question are loaded for the given users, it renders as a blank white area.
I did notice however that at least some of the objects in the views are actually there, just not visible. For instance, one view has buttons that are still "there" as you can click on them if you know where they are supposed to be positioned(and they also fire correctly) but they are not actually visible as the area is all white with no visible content. It's as if everything is loading properly but the UI just isn't cooperating in displaying objects that are actually there. The closest thing I could find was this Diagnosing run loop issue (partially frozen UI) in Cocoa application
However I'm not sure it's the same problem and there was no resolution for that either. Has anyone else ever encountered something like this?
Ok, got some new info. After doing a remote session with a user we had no luck with the hardware and the console didn't provide much insight, however we did stumble across a workaround that fixes the issue and may give some clues as to the real problem.
When the application is initially installed, we prompt the user to ask if they want it moved to the default Applications directory. They do not have to move it as it will work the same from pretty much anywhere but we do this for convenience. For the users having this problem, we noticed that they all had the app installed in the Applications folder. By sheer luck, one user accidentally chose to not move the app after reinstalling it per our support team. When the app was installed in his default Downloads directory, the problem vanished and the app worked as expected.
After testing various other directory locations(Downloads, Documents, etc.) we found that the issue only seemed to exist if the app was installed in the Applications directory. Furthermore, if the app was installed in the Applications directory, we could simply move it or copy/paste it to another directory outside Applications and when launching it from that new location the issue was resolved.
Seems like there is something specific to the default Applications directory that is causing this to happen(as odd as that sounds). Keep in mind that even when the app is installed in the Applications directory, this issue only happens to 7 people out of over 4,000.
Any ideas as to what might be special about that directory that could explain what we're seeing?
I have developed a mac application without using sandbox.
now i want to send it to the mac appSore, i buy my certificate, all is good.
I read this: Apple doc and in xcode i set the user selected file,music folder... to read/write access.
My application let the user chose from a folder any type of file, do some treatment and let the user chose where to save the new file.
To chose files, user can open folder with NSOpenPanel or with the open with functionality or drag-and-drop files.
Also the application can delete files.
I dont know if there's other things to do to sandbox the application (or a tool to test if it is sandboxed)
I come from ios this is why i'm asking :)
You can look in the Console when the application is running to view if sandboxd or pboxd logs messages referring to your application.
The format is: sandboxd[53037] ([53035]): AppName(53035)
I don't know if there are other processes who may log sandbox violation, but you can see them, if they are referring to your application.
I was wondering how we can access Safari bookmarks from another Cocoa application on Mac OS X, in a way that is safe and secure for the future.
As you may know, two mechanisms were common to retreive Safari bookmarks:
either read Safari's Bookmarks.plist file
or use the SyncServices API.
However, the first is forbidden by sandboxing (mandatory for a distribution through the App Store), and the second has been deprecated since Mac OS X 10.7 Lion.
I believe that Apple deprecated SyncServices in favour of iCloud synching, but I can't find any iCloud API that allow access to the bookmarks (1).
Any hint on where to look? Native Cocoa is preferred, but any non-deprecated, sandboxing-compatible solution is welcome.
Thanks.
(1) and, honestly, going through the internet (and thus requiring an internet connexion) to retrieve on a machine something on the same machine seems... awkward — but well, if it was the way to go at least that would be a possibility.
You can read out the bookmarks plist file even when running in a sandbox if you expressly ask the user for consent: Present an open panel pointing to the plist directory and store the security-scoped bookmark you receive from it. I did this and my app wasn't rejected for this (but for other things).
Apps in OS X that can open files to launch their respective applications often let the user choose the app that'll open the file. An example is the Finder.
I am still unclear about what's the best solution to implement this. The challenges are performance and showing the app's icon.
First, to get the list of apps, I found only LSCopyApplicationURLsForURL().
The major difficulty for me now is to get the app icons. All I have is the URLs (paths) to the apps. The only way I know of to get the icons would be to create a CFBundle object and then read the app's plist to get the icon data. But that appears to invole lots of disk access, and I could imagine it'll be quite inefficient if the app is located on a remote file server.
I believe that there's also a cached database about the apps, which includes icons and display names (without extension), and such. But where is the API for that?
Note: The app is Carbon based, but I can make use of Cocoa (NS...) functions if necessary. Also, Support for 10.5, even 10.4, would be appreciated.
Alright. I solved it eventually.
I now use the Carbon function GetIconRefFromFileInfo(), which still works in Lion, though it's marked deprecated/obsolete.
I had also tried to use QLThumbnailImageCreate(), but that didn't get me any results, oddly. No idea what I did wrong.
For Cocoa apps, [[NSWorkspace sharedWorkspace] iconForFile:path] can be used (thanks to C. Grunenberg of DevonTechnologies for this tip, where it's used with EasyFind).
I am wondering what limitations are imposed on the Mac app store. Can someone point me in the right direction? For instance, lets say I wanted to write an app that does incremental auto-backups of files on the Mac file system, is that possible with an app in the Mac app store, or would my only option be a standalone mac app?
On the iPhone, apps are self contained in their own "sandbox"? Does this same principal apply to mac app store apps?
Fellows, what the OP is really referring to is described here:
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
It is all about
Containers
Entitlements
PowerBox (daemon)
Once an application is "sandboxed" its view of the ~ "home" directory is that of a Container (which happens to be created upon first start in $HOME/Library/Containers/appBundleID/Data). Therein it finds its "private copy" of config, cache and data files. And off course it can't read anything else, unless...
... you give the application the appropriate Entitlements in the form of a codesign-ed property file (in fact, codesigning is integral part of the sandboxing concept).
One of these Entitlements is the "com.apple.security.files.user-selected.read-write" which allows the application to read and write exactly those files which the user has explicitly chosen via the standard save and open dialog respectively.
The PowerBox (pboxd) daemon then renders the appropriate file dialog in its own process space and adds the selected file paths to the list of allowed files. This is transparent to the application, that is no code changes are required - as long as the application uses the standard NSOpenPanel or NSSavePanel dialogs.
"To facilitate application sandboxing, Mac OS X v10.7 provides a trusted system daemon that is tasked with presenting open and save panels on behalf of applications running in an application sandbox. That daemon is called Powerbox (its process name is pboxd). These Powerbox-presented remote panels appear fully indistinguishable from in-process panels in terms of user experience.
Any time an application running inside a sandbox invokes an NSOpenPanel or NSSavePanel dialog, rather than showing the panels directly, AppKit automatically asks the Powerbox to present the dialog. From a developer perspective, there are no code changes required in terms of how these panels are used; this process is fully transparent." [end quote from Apple docs]
Given all that, what the OP would need (for a backup solution) are "unmediated read/writes":
"If an application chooses to derive the user's home directory in a way that bypasses Cocoa APIs (by directly invoking getpwent, for example), the application sandbox prohibits it from writing to the paths it receives (unless the application has the unmediated write entitlement, which is strongly discouraged for obvious security reasons." [end quote from Apple docs]
However the closest Entitlements which would give "free access to the file system" I could fine would be:
"
Absolute file read-only—The ability to read the files or directories at the specified absolute paths. (com.apple.security.temporary-exception.files.absolute-path.read-only)
Absolute file read/write—The ability to read or write the files or directories at the specified absolute paths. (com.apple.security.temporary-exception.files.absolute-path.read-write)
" [end quote from Apple docs]
And I am not sure whether an application could simply provide the root directory "/"
Anyway, carefully note that these entitlements are marked "temporary": Apple might remove/deprecate those entitlements at seen fit!
I believe that starting in November, Mac App Store submissions must adopt the App Sandbox. There are specific entitlements that you can request when your app is submitted to the app store, along with an explanation of why you need those entitlements. More information can be found in WWDC Session 204 video on the Developer site.
Technically, there is sandboxing on the OS X. However, applicants started manually by the user bypass those sandboxing restrictions (sometimes requiring escalation / admin verification screens).
Take a look at:
http://techjournal.318.com/security/a-brief-introduction-to-mac-os-x-sandbox-technology/
The are changing or have changed with the Lion release. Mac Store apps used to be able to do anything within the filesystem that the logged in user privs could allow but I think you are now required to use the entitlements system and hence sandbox your App.
Read this for more ideas
https://developer.apple.com/library/mac/#releasenotes/General/SubmittingToMacAppStore/_index.html#//apple_ref/doc/uid/TP40010572
This will help. Take a good look at it.
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW16
You can currently find Hype or Pixelmator on the Mac App Store.
This proves evidently that you can save to disk and read from disk, which seems a basic feature of any serious application. Moreover, Apple is pushing developers to start using incremental auto-backups of files, it would therefore be very surprising if they forbade that in the App Store, wouldn't it?