Loose words confuse, and one of the words used most loosely in macOS is permissions. This explainer tries to separate them from other access controls.

Permissions

The access permissions of files and folders are set in their attributes in the file system, stay with that item, and are applied universally for all apps and processes that try to access them.

The simplest and most basic of access controls, these can be inspected and changed in the Finder’s Get Info dialog for all accessible files and folders. They control the ability of apps and other code to read from and write to each file and folder. Normally, if you’re the named owner of a file or folder, you expect to have both read and write access, and that ensures the apps you run with user privileges can open, edit and save changed files.

Permissions are relatively crude controls, so Access Control Lists (ACLs) can refine those permissions with more specific restrictions. They were introduced in Mac OS X 10.4 Tiger in 2005, and are now applied as standard to some widely used folders including the Home folder. The presence of ACLs is normally indicated in the Get Info dialog by the words You have custom access.

No matter what security controls and privacy protection might give you access to, they can’t override the fundamental limits imposed by permissions, and can only limit access further.

Security controls

The macOS security system imposes its own controls according to its rules. Most obvious among those are System Integrity Protection (SIP) and sandboxing.

SIP was introduced in 2015 with El Capitan, and primarily puts system folders, files and some components, including certain extended attributes, beyond the reach of even the root user. The only way to get past SIP is to disable it, a serious undertaking as it has more general effects on security.

Sandboxing is security protection that limits the files individual apps can access by imposing a sandbox as set by their entitlements. It’s therefore determined by the app trying to access files, and doesn’t apply to apps that don’t run in the sandbox. As an app’s entitlements are baked into its signature, there’s nothing a user can do to alter them.

Privacy protection

macOS designates certain locations and resources as being private, and protects them using its Transparency, Consent and Control (TCC) system. Although it has a longer history, this was first implemented in its current form in macOS 10.14 Mojave in 2018, and since then has grown with every new major version of macOS. Privacy protection operates outside of file attributes, using a rule-based system applied to each app, and applies to command tools and other processes as well.

Among the folders this protects are the Desktop, Documents, Downloads, and those on removable storage. While access to individual folders is controlled, if you do encounter problems it’s usually simplest to add that app to the list of those with Full Disk Access, in Privacy & Security settings, in the first instance. That can leave a lot of apps with unnecessary access to private data, so you should periodically check through the list of apps with Full Disk Access to ensure they all still require it. Remember that Full Disk Access can’t override restrictions imposed by permissions or ACLs.

In Tahoe, privacy-protected folders include:

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

Unlike permissions and security controls, there’s no command line interface to these controls, which can only be accessed by the user in Privacy & Security settings. As a result, TCC uses an attribution chain that traces up through the call chain to an app that is responsible for the privacy settings to be applied. For example, when you run commands in Terminal, the privacy settings used by TCC are those of the Terminal app, while helper apps are normally the responsibility of their parent app.

Privacy protection is built around the user’s consent and intent. When a process tries to save a file to a protected folder that it doesn’t already have access to, you should be prompted to give your consent before TCC allows that. Alternatively, when an app tries that, it should display the File Save dialog, where you can express your intent to save the file to that folder. Without consent or intent, TCC should block that file from being saved there unless that app has been given Full Disk Access in Privacy & Security settings.

Privacy protection is the most complex and opaque of these, and can present the toughest problems to solve.

Key points

• Permissions by attributes
• Security by security system
• Privacy protection by TCC, the app and rules
• Loose words confuse.