Weird Files and Folder Permissions behavior (OS X Bug)

Catalina's new security restrictions only apply to "back-door" access to these folders. That is when an app tries to read for write from these folders without having explicity asked for that permission first. Your app can read and write to most places on the disk with no issues and no extra security problems when it is done through a normal file open/save dialog. It is only when you try to access without using that dialog that you get the permission request.

Given the combination of Full Disk Access, Files and Folders, NSOpen/Save panels, and end users telling you what the are doing, it is going to be very difficult to try to figure out what is going on. People simply may not understand or remember.

I don't know the details of what your app is doing. But given that so much power has been given to the user, your app is going to have to accept that. Users can give permisson and they can also take permission away. They may withdraw permission but still expect your app to work. Maybe they just followed some internet advice to fix a buggy app and wiped out or corrupted thier security database. You can expect things like that to become very common. Your app needs to run properly in that environment. It it can't access a folder that it should, it should alert the user gracefully and wait, gracefully, for the user to change security settings.

Hi Daniel,

Thanks for your response. I have not seen any documentation of the new security restrictions only apply to "back-door" access to these folders. Could you please provide me a link to any official documentation that states this?

Furthermore, our app is a very similar to Dropbox in that we sync up and down files/foders. Is there a way for the app to request permission to read/write to user folders (similar to iOS)? And is there a way to check if we have read/write permissions to a particular folder?

I have observed OS X prompting for permission for our app to have these permissions however I have also noticed that many times there is NO dialog prompting the user for any permission. So I it looks like I can not rely on OS X do it it for me.

Here is the WWDC video describing the new security aspects of Catalina: developer.apple.com/videos/play/wwdc2019/701/

I'm afraid that about as in-depth as Apple gets for documentation these days.

I'm pretty sure that if you use an NSOpenPanel or NSSavePanel, then you have access to those locations without any further permissions or consent. The fact that the user navigated to that location is the consent. I can't tell you in detail how Apple implemented that. In the sandbox, they use security scoped bookmarks. I also can't tell you about any edge cases or special uses, such as how a Dropbox-style app might use those locations. Dropbox runs on iOS, doesn't it? In general, I recommend that people design apps so that they would work in an iOS architecture. That is what is most likely to work going forward on the Mac. That may require a different way of thinking than you are used to.

I used the phrase "back door" on purpose. While Apple isn't going to come out and admit it, the reason for these security restrictions is due to malicious software. When it comes to security, you are not an Apple developer building great apps that bring meaning to people's lives, you are the enemy. These new restrictions are most definitely not going to "do it for you". They are designed to block malicious developers today and to slowly, but surely, make such apps non-viable entirely in the future. If you really, really want to do it, you'll have to be clever about how to implement it, not just with respect to how APIs function, but with respect to Apple's undocumented, top-secret, and obvious platform roadmap.

Now this is making a little more sense to be. Our app (and drop box) need File and Folder permissions because we launch on startup time and immediately start reading the user's documents folder. If there are new files we push them up to the server. Note this is done without any user interaction. (All the user did was login in). This explains why we need explicit file/folder permissions because the user does not explictily go to that location. Our app and Drop box is simpliy monitoring the Documents folder. Thank you so much for clearly this up for me.

The last piece to this puzzle that is still confusing even without these File/Folder permissions the App works even after a full reboot. Then all of a sudden it does not work due to not having proper permissions.

Furthermore, sometimes OS X prompts the user to give the app permission and other times it does not.

There is so much inconsitency!

You are going to have to watch the video. While it makes sense, it isn't necessarily simple or straighforward. For example, your app can work and create files in protected folders, but it can't read from those folders. There are new methods to test if a file is accessible.

Thanks! I watched the video. I understand the nuances now. This is enough for me to come up with a solution.

I do still think there is a bug with the File Permissions particularly being able to read data the app didn't explicitly create or have permissions to. I have filed it with Apple.

Thanks again for all your help! I really apperiate it.

There are some things that are not clear either from this discussion or from the video:

• What if I open a folder inside Documents, say a project folder in VSCode, it can do whatever it wants there, so this action of opening a folder from an app is giving it implicit consent to own the folder altogether?

• Can this permission be removed somehow?

• Where can I see all the implicit accesses I've given?

OK, lemme start with a link to On File System Permissions, which defines the terminology I’m using here.

What if I open a folder inside Documents, say a project folder in VSCode, it can do whatever it wants there

That depends on how you open it. If you open it using standard user-level techniques — with the standard open panels or drag and drop — then, yes, the app is given access to that directory and all its contents.

Can this permission be removed somehow?

Not in any supported fashion. If you do some digging you’ll find that this stuff is track using extended attributes, but that’s an implementation detail.

Where can I see all the implicit accesses I've given?

Ditto.

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