Gaining access to privacy-protected folders

Last week I attempted to draw distinction between the different systems that control access to files and folders, from permissions to privacy settings. This article continues with a more detailed account of how Privacy & Security works, through the macOS Transparency, Consent and Control (TCC) system. Its settings are probably the most extensive and complicated of all System Settings, and grow worse with each new version of macOS.

Many of the controls in Privacy & Security settings refer not to folders on your Mac, but concern access to private data or sensitive hardware. The list of folders and volumes that have restricted access in macOS Sequoia is extensive:

~/Desktop
~/Documents
~/Downloads
iCloud Drive
third-party cloud storage, if used
removable volumes
network volumes
Time Machine backups.

Consent and intent

Apple’s approach to privacy is founded on two basic user controls: user consent, and user intent. These are fundamentally different, and are used in different types of protection.

For an app to gain access to its built-in camera, the app has to ask to use it, and macOS then has to ask you to give your consent to that request. Although that dialog may seem tedious and even pointless, the decision is yours and not the app’s or that of macOS. If the app is for web conferencing, then the dialog may seem pointless: after all, what’s the point of opening the app if it can’t have access to your camera? But you’ll sometimes be surprised at which apps want camera access. If you simply click through every consent dialog, then you won’t catch rogue or malicious apps.

Protected locations are different. You might want almost any app to save a document you’ve been editing in your ~/Documents folder, or on a removable volume. So when you use the File Save dialog, you expect macOS to give the app that ability, by expressing your intent. Apps may access files in other ways, in which your intent isn’t expressed: a search tool might want to look in all the files in your ~/Documents folder, but you can’t express your intent for every one. So access to protected locations may require user intent or consent.

The result for protected locations generally appears in two settings:

individual folders are set in Files & Folders,
system-wide access is set in Full Disk Access.

You can’t add apps directly to Files & Folders, but you can give them Full Disk Access. The difference is in how they work.

Files & Folders

Take an example, my virtualiser Viable, which doesn’t do anything privacy-related, but does provide access to some protected folders. When first installed, it has no entry in Privacy & Security. When I try to run a VM, that accesses some protected folders. As I don’t select them in a file open or save dialog, or by drag-and-drop, I don’t express my intent to access those folders. When Viable tries to do so, I’m prompted to give consent for it to access the Downloads and Desktop folders.

If I agree to those, Files & Folders is changed, adding Viable to its list, with access to those two folders enabled. If I don’t like that, or trash that app, then it’s up to me to delete its settings there. Otherwise, the next time it won’t prompt me, as I’ve already given my consent.

In the case of Files & Folders settings, you don’t have to quit the app and open it again for these changes to take effect.

Full Disk Access

Instead of doing that, you could decide to give the app Full Disk Access, which goes far beyond those two folders. In most cases, you should avoid giving everything Full Disk Access, as you could then be caught out by a rogue app. This works differently in that you have to open Privacy & Security settings, and in the Full Disk Access list, click on the + tool at the bottom left to select the app and add it.

Unlike Files & Folders, if you change its setting while the app is running, you’ll need to quit the app for the change to register and take effect.

Once that’s done, my app is listed in the Full Disk Access section. You could then disable Full Disk Access, even delete the app from here, although in both cases that needs the app to be closed and re-opened for the change to take effect.

Single files

There’s a third possibility we haven’t seen here: what if I want to use an app to edit files in a protected folder like ~/Documents? So long as I show my intent using features like file open and save dialogs, then that should go unchallenged, and you won’t be asked to give consent for the app privacy settings to be changed.

Command tools

This is fine for regular apps, but what about command tools, as they don’t have a GUI interface? Here the rules are applied through an attribution chain, based on which app called the tool to be run. In most cases, that means Terminal’s privacy settings. So if you want tools there to have access to protected folders, you’ll normally need to give consent by adding Terminal to Full Disk Access settings.

Exceptions

Unfortunately, macOS also applies some additional restrictions on locations that can be used for specific actions. For example, you can use the log collect command to save a copy of the Unified log to a logarchive for later analysis, but if you specify a path to an external disk, then the command fails, as it can’t be saved on external storage. You can, however, save the logarchive to internal storage, then move or copy it to external storage.

Summary

Rules for access to protected folders:

If the user shows explicit intent, access is normally granted.
If the app performs access without the user showing explicit intent to use a file in a protected folder, and the app doesn’t have Full Disk Access, then the user is prompted and that app added to the Files & Folders list to allow access to that specific folder.
If the app needs consent for more general access, give it Full Disk Access.
For command tools, treat Terminal as setting their access.
Privacy controls work on top of permissions; if you or your app don’t have permissions, then privacy can’t overrule that.