Dealing with Full Disk Access and Files & Folders Access

[demitri]

I've been using these great classes in my app for a while. I'm finally getting around to updating my app for Mojave and Catalina, both of which introduced new security restrictions. This has broken a lot of my code in unexpected ways. There are cases where attempting to open a file through the open dialog will still fail unless FDA permission is given. This is turning my code into spaghetti.

The core of the problem is that there is no API to tell you if a file's access is blocked because of these restrictions, but can be given if the user turns on these permissions. See this thread from a year ago; I don't think anything has changed (certainly not for Mojave):

Reliable test for Full Disk Access?

Apple says not to assume a set of directories that fall under these permissions, but provides no way of testing whether FDA is on or not or which folders is applies to. I was thinking that AppSandboxFileAccess is the right place to put these tests and return an "educated guess" as to why a file cannot be read. It might even go as far as to put up a window showing the user how to turn on FDA and Files and Folders access.

Is there any interest in this?

[leighmcculloch]

If you wrap all file access in this library it should only prompt the user if permission hasn't already been acquired. Also if the package has gained permission for some root path everything under that path shouldnt require prompting either. Are you finding that it is always prompting?

[leighmcculloch]

Sorry I missed your were talking about full disk access being turned on outside of the app. That's a good question, if there is a way to detect it then I agree it could live in this library too, because it makes little sense to prompt for permission if full disk access is enabled. I'm not sure what the best way to do this is though. 🤔

[leighmcculloch]

In terms of whether this library should provide instructions for how to enable full disk usage I think that might be fuzzier. The goal of this library was to primarily help an application get scoped privileges which I think is the best practice for the user in most cases. I'd be inclined to add the full disk access check just as a way to skip unnecessarily prompting. What do you think? Could you share your use case?

[demitri]

I tried to make a table to go through the possible paths, but quickly realized I needed a flowchart:

macOS file access.pdf

I agree with the goal of the library; I see is as a means to answer the question: "Can a user open a given NSURL?" The problem I've run into is that there are cases in 10.14+ where the Powerbox dialog can be presented, permission given, and still not be able to open the file (see flowchart). Attempts to open the file simply fail, and there is no API that gives you, the developer, the reason why.

The flowchart outlines the paths as I understand them (there could be mistakes!). You will see a few paths where permission is requested but read access is still silently denied. In some of those cases, permission could be given if the user goes to the System Preferences and clicks the right box. It's a better UX if the program can tell the user this.

I'd be inclined to add the full disk access check just as a way to skip unnecessarily prompting.

This is the other problem. There is no API that you can use to check if FDA is on, nor if "Files and Folders" permission is on or off. See the links below for discussions on this. Apple says, "we won't tell you the list because it might change, and there is no way to check", this is not useful. There are directories we do know (e.g. Mail, Home), and they can be checked against the given NSURL. I mean, what other way is there?

This library can make a best-guess effort to:

• get permission given an NSURL
• check that bookmark data was indeed created, as now it can silently fail even if the user gives permission
• if access is denied by the OS, return a code to suggest it could have been due to FDA or Files and Folders access
• it would be nice to prompt the user in this case in the UI, but it can be optional in the API

As for my case, my program (Nightlight) searches for a particular kind of file via Spotlight. Spotlight will find them in protected spaces - but it's most places as "Home", "Desktop", "Documents"... are all protected. I have the path, but getting permission silently fails.

Hope that makes sense!

Useful Discussions:

• Reliable test for Full Disk Access?
• Re: Privacy controls need a better enable UI than going to System Preferences
• The Rules for Full Disk Access

[demitri]

@leighmcculloch Would you be interested in creating a new branch to test some of these directions, e.g. at the very least attempt to see if a file is in a "Full Disk Access" or "Files and Folders" location?

[leighmcculloch]

Yup, I'm up for exploring it. I think if we can detect if the application already has access to a file, or if we can return a specific error in the event that asking for permission will be a waste of time because that other permission is required, will be good. I'm not sure we should provide instructions yet, but that could be an improvement on-top of those which can be optionally enabled.