Prior to macOS 10.14 Mojave, the only significant limits on the files and folders which an unsandboxed app can access are set by permissions. Apps like Revisionist and xattred which incorporate directory crawlers have been able to roam free within standard Unix constraints. Try to examine or open an item to which you don’t have access either gets blocked completely, or returns an error which is easily handled in the code.

Mojave introduces additional protections to preserve the privacy of a lot of content and data, including Mail, Messages, Safari history, address books, calendars, reminders, and specific data such as location, audio and camera media. In doing so, it doesn’t follow the Unix model of permissions, particularly when the app in question is one which has been ‘hardened’ for notarization.

When a developer ‘hardens’ an app for Mojave’s new notarization scheme, they have to choose which of the new types of protected data they wish that app to be able to access. Only their options are limited, and currently don’t include Mail, Messages, Safari history, or the like.

The settings which I chose for Revisionist’s hardening do not give any access to private content such as Photos libraries, as their contents don’t have associated versions, and in any case the user shouldn’t be running the risk of tampering with any versions which might be there. That hardened and notarized version of Revisionist cannot, therefore, look inside a Photos library.

Run from a straight installation, the crawler in the notarized version of Revisionist finds and checks just four items in my Pictures folder, and can’t see inside the Photos libraries there.

A user who might want to look inside those libraries would naturally open the Privacy tab in Mojave’s Security & Privacy pane. There, listed on the left, is the Photos item, which they will then select. My notarized version of Revisionist doesn’t then appear among the apps listed, and the user has no way of adding it, as its hardening baked in the rule that it doesn’t access Photos libraries.

If they have been fortunate enough to read more widely, they may be aware that adding Revisionist to the list of apps in the Application Data pane – which doesn’t mention Photos libraries – could do the trick. As hardening doesn’t provide the developer with any option to access Mail, Messages, and similar data, this appears to be their last resort.

Sure enough, with Revisionist added to that list and enabled, running its crawler now finds and checks all 4535 files contained in those Photos libraries.

What happens, though, if the user then decides to open one of those files which is not covered by the entitlements baked into the app, but which should be permitted by the user adding the app to the Application Data list?

This is where it all goes horribly undefined. According to the transcript of session 702 at WWDC back in June:
“So if your app attempts to access any data that is part of one of the protected categories that Kelly described in his previous section, and you don’t have the appropriate entitlement signed in your app, then the system will automatically terminate it.”

The words “automatically terminate it” mean that the app unexpectedly quits, in a way that Unix doesn’t when you try to access the inaccessible. Only by browsing down many lines in the crash report do you discover that the cause of the crash is an attempt to access a protected file.

For the moment, I’m unable to check whether the user has any means of changing that behaviour, because even pointing an Open File dialog at a protected file results in an immediate crash, before the app has had a chance to learn which file it was hoped to open.

I can see that hardening an app like xattred, which works with extended attributes anywhere that it has Unix permissions, is not going to be a simple process, without losing much of its functionality.