Just when you think you understand permissions, ACLs, SIP, and macOS privacy protection, you realise that macOS is such an impenetrable warren that it misleads you completely. I refer to the strange list of preference settings which the Finder displays as being writable, but which may not be writable when you ask the question slightly differently.

This all started from an apparently simple problem: sometimes preference settings become inaccessible to the apps which need to write to them, and may need to be reset. For example, MyApp might keep its settings in ~/Library/Preferences/com.thisco.myapp.plist. If the permissions get altered on that file, changes in those settings can’t be saved to it any more, and the user has a problem. Apple started recommending a procedure of repairing or resetting permissions in the user’s Home folder to address the many problems which can result.

In an effort to make this simpler, I wrote a little app PermissionScanner which can check files in places like ~/Library/Preferences to see which aren’t readable or writable, thus need their permissions inspected and corrected. Some time ago, when people started using this in Mojave, we noticed that four files consistently came up as not being writable unless you gave the app Full Disk Access in the Privacy pane. Although this seemed strange, without Full Disk Access other files had issues too. I accepted it, and we moved on and didn’t look any deeper at the time.

When Apple revised its recommendations for resetting permissions in the Home folder earlier this year, the situation had changed, and more users running PermissionScanner started to report anomalies. These included the same four files in ~/Library/Preferences:

• com.apple.mail-shared.plist
• com.apple.homed.notbackedup.plist
• com.apple.universalaccess.plist
• com.apple.homed.plist

Some users discussed this by email with me, sending me screenshots of the permissions of those four files according to the Finder. My little app was reporting that those files weren’t writable, despite their permissions being correct. I went back to my code, spending the best part of a week and more trying to resolve this. No matter what I did, for those users there was a conflict between permissions and PermissionScanner.

It took the knowledge of Jeff Johnson @lapcatsoftware to spot what was happening: those four files are being protected by the macOS privacy protection system. Unless an app is added to the Full Disk Access list, whatever their permissions might appear to be, one of those files is effectively read-only and not writable, and the other three can’t even be read. You can’t trust the Finder to tell you whether any given file is readable or writable now.

Others have previously reported that they are protected by SIP, which is partially correct, but they don’t appear in the SIP protection list and don’t bear a protective extended attribute. Instead, it appears that their protection is recorded in some more secret place. Neither is it exposed in the Privacy pane: as there’s no user option to turn it off, and all apps with Full Disk Access will see these files as being writable, this isn’t an option. It appears to be wired into a kernel extension, which is in turn part of macOS.

These four files thus appear to be unwritable in practice to all apps which don’t have Full Disk Access. If you run PermissionScanner or any other app or tool which doesn’t have Full Disk Access, they will be reported as being unreadable and/or unwritable. Inspect their permissions in the Finder, though, and they’ll appear to have both read and write access.

You can use PermissionScanner to check for other files like these. Turn its Full Disk Access off, open the PermissionScanner app, and scan any folder that you’re interested in for writable (or readable) files. Quit the app, restore its Full Disk Access, and scan again. Items which appear on the first list but not the second are those which are on this secret protection list. I have no idea how many you’ll find in your Home folder beyond the four listed above, but these are all being protected secretly by the privacy protection system in Mojave and Catalina. Apple just forgot to mention it.

I am very grateful to Jeff Johnson @lapcatsoftware for pointing me in the right – if strange – direction, and showing that this is a privacy protection problem.