11

MacOS Mojave has extended the effects of SIP into the home directories of users. By default, access is denied to many directories in a user’s home directory. A few examples of these directories follow.

~/Library/Messages
~/Library/Mail
~/Library/Safari
[… etc.]

In order to access these directories from a terminal, the terminal application must be defined in System Preferences > Security & Privacy > Privacy > Full Disk Access. The configuration works, except for the following directory on my system. The same behavior may exist for other data in containers - not sure.

~/Library/Containers/com.apple.mail/Data/DataVaults

The intriguing behavior is easy to reproduce. The directory isn't even visible.

cd ~/Library/Containers/com.apple.mail/Data
ls
ls: DataVaults: Operation not permitted

I use rsync to mirror my home directory to an external hard drive; but, I can no longer do so because rsync complains, "IO error encountered -- skipping file deletion," which breaks the mirroring effect. I do not find any documentation on this issue. Apple support have no idea. Why is this directory special, and how can we gain access to it without disabling SIP?

Results of Further Investigation with SIP Disabled

According to System Information, the Mojave upgrade was performed on 24 September 2018. The directory was also created on the same day. My user owns the directory, and the staff group is the group owner. Its permissions are 0700. It has extended attributes as indicated by the @ symbol. No ACLs. No flags.

xattr -l ~/Library/Containers/com.apple.mail/Data/DataVaults

com.apple.quarantine: 0082;00000000;Mail;
com.apple.rootless: Mail

ls -lO DataVaults
(no result; exit 0)

After disabling SIP, deleting the directory, and reenabling SIP, the directory reappears with the same permissions as soon as Mail is opened. Mail (Version 12.0 (3445.100.39)) has no plugins.

Results from a Fresh Installation on Oct 16 2018

The directory does not exist after formatting and reinstalling. I still have no clue how it was ever there to start.

Results from an upgrade on March 29, 2019

The directory has reappeared coinciding with the upgrade to Mojave 10.14.4 (18E226) and/or Mail Version 12.4 (3445.104.8).

Improve this question
3
  • The directory is protected by either a file flag, ACL or extended attribute. I have notice that many of the files and directories acquired the com.apple.quarantine attribute after upgrading to Mojave, for example. For my own backups (using restic from Homebrew), I simply ignore these bits of ~/Library as none of them seems to concern me or what I usually do anyway. I have some 24 of these myself.
    – Kusalananda ♦
    Commented Oct 1, 2018 at 13:53
  • Sorry, I re-read you question and indeed, after adding the iTerm2 (in my case) to the apps with "Full disk access", the backup now runs without issues (thanks for that!). I can't say more about your case. On my machine, I can see that particular directory and it contains symbolic links to some of the directories in my home directory (the "default" ones like Documents, Movies, Music etc.).
    – Kusalananda ♦
    Commented Oct 1, 2018 at 14:01
  • Can't say more. I don't have that directory/symlink. Did you upgrade or re-install? Does "DataVaults" ring a bell regarding any application or feature you have previously used?
    – Kusalananda ♦
    Commented Oct 1, 2018 at 14:08

1 Answer 1

Reset to default
8

The DataVaults directory has to do with entitlements. Access is prevented unless the owner of the entitlement grants the access. The entitlements for Mail.app can be listed as follows and provides an XML plist.

codesign -d --entitlements - /Applications/Mail.app/

At this time, the only remaining method to acquire access to the directory is to turn off SIP. In regard to my rsync issue, I opted to keep SIP turned on and utilized the rsysnc option, exclude, to ignore the DataVaults directory, which, by the way, is devoid of content.

From a comment the blog at Eclectic Light Company, offering more clues:

/var/folders/t9/[long ID]/C/com.apple.QuickLook.thumbnailcache” is a DataVault, which is a new type of privacy container that Apple introduced sometime around 10.13.4. These files/folders are identified by the “UF_DATAVAULT” file flag. These are implemented via SIP (not technically sandboxing, but the same gist). Applications need an entitlement to make or access specific data vaults, or even to stat() a DataVault folder.

These devices are worth some deeper investigation. Apple doesn’t (and apparently has no plans to) issue these entitlements to third-parties. Consider the implications of that – Apple is creating a platform where only data created in Apple applications gets the highest level of security.

Also consider that you (the user) can’t see what’s in these DataVaults without turning off SIP. It’s hard to tell what Apple is keeping in these, but some of them are a bit alarming. Here are just a few known data vaults:

~/Library/VoiceTrigger/SAT

~/Library/Containers/com.apple.mail/Data/DataVaults /private/var/folders/0z/fs4vdwmx6g31n69qt5v5ff580000gn/0/com.apple.nsurlsessiond

That first one apparently has “Siri Audio Transcripts” – everything you’ve ever uttered to Siri on your Mac.

I did not find a flag on ~/Library/Containers/com.apple.mail/Data/DataVaults, and a clean installation of Mojave caused the directory not to appear again since.

A summary overview of access controls was also published.

Improve this answer
1
  • You could also consider the rsync option --ignore-errors.
    – dave
    Commented Feb 11, 2019 at 4:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .