Read and write access to files in macOS has become complicated by its combination of Unix permissions, security and privacy protections. One obvious danger is to refer to them all as permissions, which can only lead to confusion. You won’t then know whether to fix them by opening the Finder’s Get Info dialog, or looking in Privacy & Security settings.
Mounting
The most basic requirement to access a file is that it must be on a volume that’s mounted for the actions you want to take. In Catalina, the System volume was mounted read-only, but in Big Sur and later it’s not mounted at all. Instead, a read-only snapshot, the SSV, is mounted. If you want to be able to write to a file, then it must be in a volume that is mounted to allow you to do so.
System Integrity Protection (SIP)
The next hurdle is whether the file comes within the scope of SIP, which can block all access, or let you only read the file. This is usually easy to spot, either because you can’t even view the contents of the folder containing the file, or Get Info reports that only system has Read & Write access, and you have none. If it’s absolutely essential, you could then disable SIP, but never do that lightly, when you don’t fully understand what you’re doing, or when an untrusted source tells you to.
Unix 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.
Privacy protection
If you are allowed to read or write a file according to its permissions, there’s one final hurdle to negotiate, that of privacy protection. This is applied in two systems, depending on whether access is made using a standard Open or Save dialog, or an equivalent. If it is, that’s your intent and normally handled via Media Access Control; otherwise, if it’s an app that’s trying to access the file on its own behalf, then that may require your consent in Privacy & Security settings.
Locations
macOS designates certain locations and resources as being private, including:
- ~/Documents
- ~/Downloads
- ~/Desktop
- removable volumes
- iCloud Drive
- third-party cloud storage
- network volumes.
There are also subtle differences between those for determining read and write access that can appear baffling even when you understand how they work.
Gaining access
The first step in determining whether a file operation should be permitted is for the kernel’s Media Access Control to determine whether the location and operation are controlled. If they are, the folder or file is checked to see whether there’s a valid Media Access Control List allowing access to proceed. If there is, the request is granted. Media Access Control Lists aren’t exposed to the user, or reflected in Privacy & Security settings, which explains why some operations that appear not to be allowed can succeed.
If there’s no valid Media Access Control List allowing the operation, the request is handed over to the Transparency, Consent and Control (TCC) system, which uses Privacy & Security settings. When possible, TCC will display a dialog inviting you to give your consent to that app gaining access to that specific location. If you agree, the app is then added to the list in Files & Folders with that location enabled. That isn’t something an app or user can control, only TCC can.
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.
There’s also the Full Disk Access list, which again is outside the control of apps, but within your control. You can add an app to the Full Disk Access list, and it will then be given full access to all privacy-protected files and folders its permissions allow. Those last three words are crucial: giving an app Full Disk Access only allows it access to items that are already allowed by permissions.
Gaining access to a file or folder requires
- its volume to be suitably mounted, and
- no SIP restriction, and
- acceptable permissions, and
- Media Access Control approval with user intent, or
- app and location approved by user consent in a TCC access list.
