Granting full-disk access to my sandboxed app not working

I'm experimenting with full-disk access to my app and can't make it working. Here is list of steps I did:


Sandbox is turned ON. In fact the entitlements file looks like:

<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>


  1. I created archive of the app and tried to distribute it using boths Developer ID or Development methods
  2. I placed the binary of my app to /Applications folder
  3. I went to System Preferences -> Security & Privacy -> Privacy -> Full Disk Access and added access to my app in /Applications folder
  4. Of course I'm NOT attached to the app with Xcode

I'm testing it in Xcode 11 and on Catalina. It's dummy app, opening 

NSOpenPanel
to let user select archives to decompress and tries to decompress it in the same directory using libarchive framework.


Any hints? Am I doing anything wrong?

Up vote post of martinpilch Down vote post of martinpilch
15k views
Posted by
martinpilch
Reply
Add a Comment

Accepted Reply

Thanks for the explanation.

The App Sandbox does support the concept of related files — see the Related Items section of the App Sandbox Design Guide — but this probably won’t help in this case. Most compression utilities want to be able to:

  • Accept a directory and create an archive next to that directory

  • Accept an archive and create a directory next to that archive

In both the cases the directory doesn’t have an extension, which prevents you from using the related files mechanism because that’s keyed off extensions.

There’s three ways around this:

  • Drop, or radically loosen, the App Sandbox

  • Present the user with a save panel for the output

  • Output to a directory chosen by the user up from

None of these are ideal, with the first one only being feasible if you’re distributing outside of the Mac App Store.

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

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

There’s a number of things to unpack here. You wrote:

Also trying to submit this question in Chrome results in "Bad Message 431 reason: Request Header Fields Too Large".

I’ve seen reports of this from other folks but I’m unable to reproduce it. See this thread for more.

Apple's ommision of gltf reader support in ModelIO requires me to supply my own reader

Model I/O is far outside of my area of expertise so I can’t help you with that aspect of this. However, my general advice is that, if the system frameworks don’t do what you need, it’s a good idea to file an enhancement request describing your requirements.

Please post your bug number, just for the record.

The "Related Items" seems to imply the same name with different extensions

Correct.

I'm trying to read gltf files which consist of json, a bin file, and a series of png images all in the same folder. How do I ship a viewer for this, if the viewer must be sandboxed, but the sandboxed app can only read the .gltf file that was supplied.

There’s two parts to this:

  • Initial access

  • Retaining access

There’s a reasonable story on the retaining access side of things, namely document-scope bookmarks.

Unfortunately there isn’t a good story when it comes to getting initial access. The only real option you have is to analyse the set of files you need access to and then present an open panel tailored to that set. For example, if it’s a single file set the prompt to say “Please locate file X” whereas if it’s multiple files set it to say “Please locate the directory containing files X, Y, and Z.”

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment