Granting full-disk access to my sandboxed app not working

Question

martinpilch OP

Created Oct ’19

Replies 16

Boosts 0

Views 17k

Participants 8

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/>

I created archive of the app and tried to distribute it using boths Developer ID or Development methods
I placed the binary of my app to /Applications folder
I went to System Preferences -> Security & Privacy -> Privacy -> Full Disk Access and added access to my app in /Applications folder
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?

Answered by DTS Engineer in 390753022

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"

Boost

Answer 1

DTS Engineer OP

Apple

Nov ’21

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"

0