Permissions, privacy and security: who’s in control?

Accessing files and folders isn’t as simple as it used to be. There was a time when, if a file was in your Home folder, you had full rights over it, and apart from those parts controlled by root, you had free roam. Now macOS plays evil tricks: you try to save a file in ~/Documents only to be told that you can’t, and even when you’ve assumed root privileges much remains out of your control. This article explains five barriers that you may have to negotiate.

Those are:

Permissions were part of Mac OS X when it was introduced nearly 25 years ago, and provides basic controls over which users and groups can read or write items, in a system common to Unix and many other operating systems.
Access Control Lists (ACLs) refine those permissions with more specific restrictions on access to items, and were introduced in Mac OS X 10.4 Tiger in 2005.
Privacy controls enforced by the Transparency, Consent and Control (TCC) system have included restrictions on access to specific folders since macOS 10.14 Mojave in 2018.
System Integrity Protection (SIP) was introduced in 2015 with El Capitan, and primarily puts system folders beyond the reach of root.
App sandboxing is security protection that limits the files individual apps can access by imposing a sandbox as determined by their entitlements.

For any app including the Finder to have access to a file or folder, all five of those must give approval.

Permissions

The simplest and most basic 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 that the apps you run with user privileges can open, edit and save changed files. There’s also the Locked checkbox that might seem obvious, although it often gets overlooked as a cause of problems when saving a file.

Some locations are particularly sensitive to errors in permissions, such as all those property lists containing settings for apps and services stored in ~/Library/Preferences. They are mostly handled by a background service cfprefsd, but if permissions have become changed so that it can’t access a property list it needs to use, all sorts of strange errors can result. In the past measures have been used to correct or repair those permissions, but those problems should now be long since past, and repairs are generally unnecessary and potentially dangerous.

ACLs

Access Control Lists, ACLs, add a more sophisticated system for enforcing more specific restrictions that cover a wide range of features. Their only common use in modern macOS is to preserve standard structures of folders in the Home folder. Regular Posix permissions don’t do that well, so a common ACL used is
group:everyone deny delete
to prevent anyone from deleting the folder it’s applied to. You should find that ACL on each named user folder and the Guest folder in /Users. Within each user folder, it’s normally applied to all the standard folders, including Desktop, Documents, Downloads, Library, Movies, Music, Pictures, Public and Sites, and on some folders within ~/Library.

The result of that ACL is that any attempt to remove that folder fails silently, so preserving the standard layout. But it doesn’t affect access given to the contents of those folders, nor can it be held responsible for errors when trying to read or write files within a protected folder. Unfortunately, the Finder’s Get Info dialog isn’t exactly forthcoming about the presence or effects of ACLs, merely stating that the user has “custom access”.

Thankfully, some GUI tools give good access to ACLs, and my favourite remains TinkerTool System, which has excellent support for them, and much more besides. It’s most valuable in displaying Effective Permissions.

Built-in tools are provided in Terminal. Show all ACLs using the command ls -le to return entries such as
drwx——@ 5 hoakley staff 160 8 Oct 12:09 Desktop
0: group:everyone deny delete
drwx——@ 81 hoakley staff 2592 17 Feb 15:42 Documents
0: group:everyone deny delete

You can add an ACL using chmod, such as
chmod +a “everyone deny delete” MyFolder

Privacy protection

macOS designates certain locations and resources as being private, and protects them using its Transparency, Consent and Control (TCC) system. Among the folders that this protects are the Desktop, Documents, Downloads, and removable storage. While access to individual folders has fine control, 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. Note that Full Disk Access can’t override permissions or ACLs.

In Sequoia, privacy-protected folders now include:

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

SIP and security

In principle, System Integrity Protection (SIP) should only apply to system files, but it’s also used to lock down some other components, including com.apple.macl extended attributes, which can be attached to user files. Those have been implicated in some problems in which regular user documents become locked down, and typically won’t save any changes. Although the exact role and use of this extended attribute isn’t clear, it’s generally accepted as designating an app that’s approved to edit that file, so providing document-specific privacy control.

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”.

com.apple.macl extended attributes are normally protected by the same mechanism that applies SIP, so any attempt to remove them is likely to fail. One workaround for that is to pass the file through another volume, so that when it’s copied back the extended attribute is no longer protected, and can be stripped.

These problems appear most likely when apps other than that set as the default app to open a document type are used to edit files. Another approach to their solution is to select an affected document in the Finder, Get Info, set it to Open with the default app, then click on Change All… to reset all others to that default app.

Sandboxes

Sandboxing is a security feature that individual apps can opt into. As it’s a requirement of those distributed through Apple’s App Store, it’s now common in third-party software. The starting point is to restrict a sandboxed app to the folders created in its sandbox, saved in its folder in ~/Containers. As this severely limits the usefulness of most apps, it’s common for them to have entitlements that extend their ability to access files and folders beyond that basic sandbox.

As this is controlled by the entitlements system and baked into the app’s signature, it’s not something that the user has any control over. If a sandboxed app is unable to access files or folders that you need to use, contact its developer.

What can you change?

Permissions are generally simple and easy to control. Beware of changing those in Library folders, but your documents and other files should be straightforward to manage.
ACLs are more obscure and complex. Unless you understand what you’re doing, leave them well alone.
Privacy controls are extensive and fraught. The only control you have here is giving apps Full Disk Access when needed. Check that list periodically to ensure you haven’t been overgenerous.
SIP shouldn’t be tampered with unless you fully understand what you’re doing. On Apple silicon Macs disabling it reduces boot security to Permissive, with other consequences. Details of fine control using csrutil are here.
App sandboxing isn’t within user control.