In our Mac App we have following credential to entitlement.plist which enables us to read/write to user's file system followed by file browser dialogue:
com.apple.security.files.user-selected.read-write
That does mean we able to read/write a file/folder if once accessed by file browser dialogue. We never able to read/write to files/folder if not accessed by file browser dialogue at least once in an application life cycle.
I didn't found any other possible credential too to entitlement.plist which can enable us read/write to files/folder by completely removing any use of file browser dialogue. Is there any way we can achieve this?
I assume your app is Sandboxed and if so, it's only possible to access the filesystem as defined here:
Powerbox and File System Access Outside of Your Container Your
sandboxed app can access file system locations outside of its
container in the following three ways:
At the specific direction of the user
By using entitlements for
specific file-system locations (described in Entitlements and System
Resource Access)
When the file system location is in certain
directories that are world readable
The OS X security technology that interacts with the user to expand your sandbox is called Powerbox. Powerbox has no API. Your app uses Powerbox transparently when you use the NSOpenPanel and NSSavePanel classes.
Well, the whole point of Sandboxing is to actually don't allow you to access user's files without their knowledge.
The only thing you can probably do is to use com.apple.security.temporary-exception.files.absolute-path.* entitlements to access some specific (read hard-coded) file system locations. You can learn more about temporary exceptions here: App Sandbox Temporary Exception Entitlements.
But keep in mind that you'll have to explain to the Apple Review Team why you need those exceptions in the first place.
Related
I am distributing my OS X application on individual USBs and, for this reason, everything must be self contained.
The app itself lets users input information and then saves this information to an existing text file (specifically an ObjectDB database). Herein is my problem.
I'd like to keep this text file inside the app itself (i.e. inside the Content folder) so it's out of the way and can't be deleted by the average user. But once the app is signed, it seems the text file can't be altered with any new information without getting flagged by Gatekeeper. Is this really the case? There's no way to store data files within apps now?
I'd appreciate any suggestions. Thanks.
Yes, you are correct. If you modify the application package, the signed package is no longer valid. That's kind of the purpose of signing a package.
Your options are to store the text file in a temporary folder on the user's computer, or to instruct your users to disable gatekeeper (don't do this).
I'm currently adding Sandboxing support to my app.
Having give permission to my app to access a folder (by dragging it onto my Window) and I would now like to revoke that permission so that I can retest what happens before that permission is given.
How can I do that?
I'm not yet using URL bookmarks, and yet the permission persists across restarts of the application. I don't know if this is because it's a folder rather than a file?
Before you change the permissions of file or folder, you must store the current one for later use. I have never seen a method or system-call to restore previous permissions after a change.
I'm trying to delete files inside application folder from my Cocoa application. By enabling Sandbox mode, I'm not able to delete files inside application folder.
This Sandbox mode has some option for enabling Read/Write access to downloads, pictures, movies, music and user selected file.
Before that I enabled Read and Write Access for user selected file and done my deletion using NSOpenPanel. It works fine and deletes files inside application folder but it opens panel every time when I run my app. Here I dont want any user interaction/permission to delete files inside application folder. Is there any solution to delete files with above defined constraints.
You need to use Security-Scoped Bookmarks:
Your app’s access to file-system locations outside of its container—as granted to your app by way of user intent, such as through Powerbox—does not automatically persist across app launches or system restarts. When your app reopens, you have to start over. (The one exception to this is for files open at the time that your app terminates, which remain in your sandbox thanks to the OS X Resume feature).
I have a mac AVRecording app, which records a video and save it to a location selected via NSSavePanel. It was working fine till I sandboxed the app.
For sandboxing I have added the following entitlements
com.apple.security.files.user-selected.read-write
com.apple.security.assets.movies.read-write
com.apple.security.files.downloads.read-write
This enables saving to Downloads and movies folder only.
How is it possible to save my file to any desired location, Desktop, Documents etc ?
It's not clear from your question whether you are referring to saving a particular file (in which case you can use the NSSavePanel and manually copy the file using NSFileManager to write the file into the user-specified new file), or whether you are referring to having the user choose a location for all future downloads.
If you want to prompt the user for a location to use for future downloads, you'll need to use the secure bookmark entitlement and secure bookmarks to retain access to the folder.
There's another stackoverflow answer about sandboxing which covers the process of saving and using the secure bookmark.
From Apple's documentation, I didn't understand if there's any way to get pre-approved entitlements to edit files in a specific folder located in the system /Library folder, without asking the user to choose this specific location via NSOpenPanel or similar.
I don't mind, and would actually like, to ask for the user's credentials to make such a change, at specific points in the application's lifetime; but letting the user choose which folder to modify just doesn't make sense in my case.
Found it - the application needs a File Access Temporary Exception entitlement.