Fixing cron jobs in Mojave
macOS Mojave introduces a new access control mechanism that lets you decide which apps should have access to the calendar database, the user’s contacts, the camera and microphone and even access to the whole drive.
That’s great! (except it breaks some things)
Those familiar with UNIX-like systems may know about
cron, a tiny, well-designed job scheduler that’s installed in all macOS systems and most Linux distributions.
Cron lets you set time-based rules for job execution, so that you can automate things like backups, health checks, setting safe file permissions, etc.
With the introduction of Mojave’s access control mechanism, cron jobs can no longer access certain directories because they hold sensitive data, but what happens when our cron job works with that data?
My backup.sh script
I have a script, called
backup.sh, that grabs all my files, dotfiles, Calendar database and Things.app database, tars them together, encrypts the tarball and pushes the backup to my NAS at home.
I schedule it to run hourly, so once I get home, it pushes the day’s backups to the NAS, great!
backup.sh needs to access certain subdirectories of
~/Library in order to grab the Calendar and Things database, but Mojave doesn’t let it anymore.
Mojave let’s you add apps and binaries to the “Full Disk Access” whitelist, so let’s see which binary runs my cron jobs:
$ ps aux | grep cron
root 201 0.0 0.0 4295936 1188 ?? Ss 11:50PM 0:00.31 /usr/sbin/cron
Here we see that the binary that runs the system’s cron jobs is
Granting Full Disk Access to cron
Go to System Preferences > Security & Privacy > Privacy > Full Disk Access:
Click on the (+) icon to add an item to the list
Gto open the Go to Folder… dialog, type
Look for the cron file, select it and click Open:
That’s it! Now my script can access my user’s
~/Library folder and all it’s contents!
Warning: this is not a great idea security-wise, if a malicious actor can create cron jobs or edit the scripts ran as cron jobs, he or she would have Full Disk Access too. Monitor the system’s installed cron jobs manually or with a tool such as KnockKnock and proceed with caution.