macOS Mojave is Apple’s most complex Mac operating system in terms of the controls which it places over access to files and folders. If you still think that this is all done by regular POSIX permissions, you may find this article illuminating, if not downright scary.

POSIX Permissions

Yes, permissions are still there, and form the fabric of normal access controls. You can view and modify them using the Finder’s Get Info dialog, and of course in Terminal.

I have written about these in detail in this article about permissions themselves, and here about owners and groups.

Permissions can still cause problems, most notably those set in your Home folder. If those go awry, then that can cause various symptoms and merit repair.

Access Control Lists (ACLs)

These are also old, and were introduced to provide finer controls than POSIX permissions. In macOS, they haven’t caught on, partly because of their complexity. It’s three years since I last wrote about them here, but as far as I am aware, they have neither changed since, nor become any less unpopular.

I haven’t come across any problems arising from the use of ACLs, as they still seem so uncommon.

SIP system file protection

System Integrity Protection was introduced in macOS 10.11 El Capitan, initially just to protect key system files and folders. Since then its protection has steadily extended to cover almost all of what gets installed in macOS. Here, I’ll use the term SIP to refer specifically to the read-only protection provided by macOS to items listed in the ‘rootless’ configuration file at /System/Library/Sandbox/rootless.conf, and those with an extended attribute of type com.apple.rootless.

As far as the Finder and Terminal are concerned, these are normally seen as being owned by system, with only that owner having Read & Write access; others are only allowed Read access, so they display normal folder and file icons. With SIP enabled, apps and other software can only read these protected items. I have explained how this affects extended attributes and other issues in this article.

macOS only allows removal and modification of these protected items by apps and software which have an Apple signature with the specific entitlement. If you want to change them in any way, you have to disable SIP in Recovery mode first.

Although this ‘rootless’ approach has generated a lot of argument, it has significantly improved not only macOS security, but also what used to be a problem of system components acquiring changed permissions, which then needed repair. Users should only ever disable SIP when they have very good reason, and know exactly what they are doing. For you and me, that means leave it well alone.

TCC privacy protection

TCC, the Transparency Consent and Control system, is also quite an old feature of macOS, but in Mojave has gained all sorts of additional powers which limit access to private data, features such as Location information, automation and event recording, and hardware, in the built-in camera and microphone.

This is controlled by a mechanism similar to that of SIP, and many refer to TCC as being another part of SIP. However, it involves additional mechanisms, including the service tccd and databases which allow third-party software to gain access to protected data and resources, provided that behaviours follow TCC’s rules.

Currently, TCC’s protection covers mainly folders in ~/Library, such as Calendars, Cookies, Messages, Mail, Safari, and Suggestions, but extends to /var/db/dslocal/nodes/ and possibly other locations outside the user’s Library folder. Its protected folders and files are not marked in any obvious way, and remain owned by the user with full Read & Write access. But any app which goes near them must satisfy TCC’s requirements with entitlements and usage strings which are used in its consent dialogs.

It you want to access TCC’s protected items from Terminal, the simplest approach is to add the Terminal app to the Full Disk Access list in Privacy. I have provided much more information about TCC and privacy control in Mojave in articles such as this and this.

DataVaults

Introduced in later releases of High Sierra, and used more in Mojave, are folders to which only Apple’s software has even read access, DataVaults. My account here is largely based on comments generously provided here by an anonymous source, as these don’t appear to have been mentioned anywhere by Apple (not even at WWDC 2018), nor can I find other descriptions.

DataVaults are folders to which neither the user nor third-party software has any access at all. The only software which can see and work with their contents are certain Apple-signed products which have a specific entitlement to do so. At present, all Macs running Mojave have at least one, which contains the QuickLook cache, at /var/folders/t9/[long ID]/C/com.apple.QuickLook.thumbnailcache Depending on what other features and apps you use, you may also find them at three additional locations:
~/Library/VoiceTrigger/SAT
~/Library/Containers/com.apple.mail/Data/DataVaults
/var/folders/0z/[long ID]/0/com.apple.nsurlsessiond

The first of those apparently contains Siri’s audio transcripts, another potentially very sensitive collection of data.

These are visible in the Finder, where they have a blank document icon but are also shown as folders. Inspect them with Get Info and you’re only told their size, and that you have “unknown access”.

In Terminal, they don’t even appear in directory listings, and any attempt to access them results in an error of Operation not permitted.

You can gain access by turning SIP off, when they can be seen to have a special flag of UF_DATAVAULT. Until more is known about these, the message to users is to leave them well alone.

(I am very grateful to the anonymous person who provided information about DataVaults.)