It might seem like the user is now the last to have any control over which documents and files apps can access. When you can’t open or save a document, how can you tell what’s wrong? Is it a permissions problem, SIP, privacy protection or something else? This article gives clues to help you work that out.

Permissions and ACLs

The oldest and most straightforward of these controls are regular POSIX (Unix) permissions. Each file and folder has settings for its owner, group, and everyone else, to determine whether they can read, write or (where appropriate) execute that item. No matter what else might grant access, if a document’s permissions don’t allow it then you aren’t going to succeed.

Thankfully, basic permissions are usually quick to identify and correct in the Finder’s Get Info dialog, but they can be made more complex with Access Control Lists (ACLs), introduced to OS X in 10.4. These provide finer controls over features such as who can list folder contents, change extended attributes, permissions and ownership. When those apply to an item, its Get Info dialog reports that users have “custom access”, although the Finder doesn’t provide any means to set or change ACLs, for which you’ll need a utility like TinkerTool System. Fortunately, they remain little-used, and you’ll be unlucky to run into trouble with them.

SIP

System Integrity Protection (SIP) has been one of the primary mechanisms used by macOS to protect itself. Introduced relatively recently in El Capitan (2015), in those days it wasn’t uncommon for key system files to become damaged or corrupted. Before El Capitan, the only thing standing between system files and an attacker was the need to gain root privileges so you could negotiate permissions.

SIP took all those system files out of reach of even the root user (consequently being referred to as rootless): using a combination of the rootless.conf file stored in /System/Library/Sandbox and the com.apple.rootless extended attribute, the contents of most system folders came under SIP’s protection. The only way a user can circumvent this is by turning SIP off when booted into Recovery mode and using the csrutil command from there.

Since El Capitan, Apple has steadily increased SIP’s coverage to include all its bundled apps and tools, and this hasn’t changed with the introduction of the Signed System Volume (SSV) in Big Sur. SIP is easy to spot in the Finder’s Get Info dialog, as only the System has write access, and permissions are again described as “custom access”.

Privacy and TCC

Even when you have the correct permissions, and SIP isn’t involved, read and write access to some locations can be blocked by the privacy controls in macOS, a subsystem for Transparency, Consent and Control, the dreaded TCC. While it manages access to services and features like camera and microphone, and controls over other apps, TCC also restricts disk, folder and file access. This is confusingly controlled by two interrelated categories in Privacy & Security settings, Full Disk Access and Files and Folders.

Those don’t govern access to iCloud, which, while also controlled by TCC, is in System Settings > Apple ID > iCloud Drive > Options. This is further complicated by the protection given to some data collections, such as Contacts’ address book, Calendars and Photos libraries, each of which merit their own category in Privacy & Security.

In most cases, more recent apps should guide you to the settings they need, and you can’t simply add an app of your choice to gain access to your photos, for instance. Full Disk Access is different, though, as you have full control over the apps listed there. This also covers access to other data collections such as your Mail, Messages, Safari, and Time Machine backups.

In most cases, any need to give an app Full Disk Access should be explained in its documentation, or should be apparent from what you want it to access. Sadly, there’s no generic guide, and you may not realise the need until you come to try to access a protected location.

App-specific limits

While those controls apply to every app and command tool, some apps are further limited in the locations they can access. This most commonly results from their being run in a sandbox, a requirement for all those delivered by Apple’s App Store. Sandboxed apps are given their own container folder in the Library in your Home folder, to which they have full read and write access. By default, they don’t enjoy unrestricted access to other parts of your Home folder, but can be given them using a system of entitlements, which are baked into the app when it’s created and can’t be modified by the user.

If you encounter access problems when using a sandboxed app, first check its documentation, and any Q&A or other information provided by the developer, which should explain. If you can’t get an answer from those, try contacting that app’s support service, as it’s always possible that its entitlements have been misconfigured and need correction.

Maybe it’s not quite so cynical to think it’s a miracle when an app can access its documents without hindrance.