How do I grant root access to user files in Mojave?

Question

I upgraded my laptop to Mojave. For years, my backup strategy has included using rsync (MacPorts rsync 3.1.3) to copy files to a file server. This stopped working properly, now showing some errors indicating permission problems with opendir and get_xattr_data, specifically with certain ~/Library folders.

I use launchd to run rsync inside a script located in /usr/local/bin.

As part of my troubleshooting, I went into Terminal and su'd to root. Then cd'd to my user's ~/Library and tested access in some of the folders. The system reported permission denied.

Through Security & Privacy, I gave rsync Full Disk Access, but that didn't resolve the issue.

I'm assuming this is an issue resulting from Mojave's security or privacy settings as I've never seen root not have permission to files. In order to resume my backup processes, I need root/launchctl to be able to access files.

What has changed in Mojave that is limiting root's access? How do I mitigate this limitation as it relates to rsync?

---

The possible duplicate seems to confirm the need to adjust settings in Security & Privacy, but so far adding Terminal and rsync to the list of allowed apps does not allow the backup to succeed. I'm working to add the script I use to run the backup, and will adjust my question when I get that tested.

Answer 1

As documented in this post among some other places, MacOS Mojave implements additional security protocols that even affect root's access to user data.

The solution in the linked question provides the basic method I used to resolve my issue.

For custom-built scripts that will run through launchd, the administrator of the computer on which the script is to be run must add that script to Security & Privacy to give that "app" permission to access user data.

It was not necessary to add launchd or rsync (in my case) to Security & Privacy.

I have not researched if there is a way to do this via Terminal, which it seems would be necessary for those administering a large number of clients.

========

Update: I've also learned that if you add a script, and you later make changes to that script, you need to delete it from the Security & Privacy-->Full Disk Access, then add it again. Perhaps macOS creates a hash that is checked?

========

Update w/ Catalina: I do not recall if I had System Integrity Protection disabled on Mojave, but it appears to be required to be disabled in Catalina. I know SIP doesn't have to be disabled for OS versions prior to these.

Disabling macOS SIP allowed the script in question to start running again. This is not ideal, so I'll be researching other approaches.

Answer 2

Not quite an answer to your problem, but it's very similar/related...

When writing a shell script that's run by cron, e.g. using rsync in a script to backup your files on another server.

You will notice that adding "Terminal.app" to the "Full Disk Access" does not work, because cron does not use "Terminal.app".

You could grant "Full Disk Access" access to the rsync program, and that solves some of the permission problems, but this is not enough if you need access to:

~/Pictures/Photos Library.photoslibrary ~/Library/Application Support/AddressBook

Instead, you should add cron to "System Preferences > Security & Privacy > Full Disk Access".

I did this by running open /usr/bin/, which opened a Finder window that allowed me to easily drag/drop the cron program into the "Full Disk Access" list.