In your case you have to add
cron as "parent" app to the user's Security & Privacy > Privacy > Full Disk Access apps/execs.
Depending where to read the script from and where to write the log file to, you have to add
cron to the Full Disk Access apps. Almost all default folders in the user's home are protected (Documents/Downloads/Desktop - I haven't checked Pictures/Movies/Music but I think they are protected too and obviously the wrong folders to add shell scripts or log files) by Catalina's system policy.
If the script and the log reside in user created and thus unprotected folders (e.g. the script in ~/bin and the log file in ~/log) it works without adding cron to the Full Disk Access group.
To add the exception:
- click the + button
- hit ⌘⇧G
- double click the
You can check this kind of errors by opening Console.app and searching for the shebanged exec in the script (here
error 15:19:00.369105+0100 kernel Sandbox: bash(4556) System Policy: deny(1) file-write-data /Users/user/Desktop/test/cronjob2.log
error 15:19:00.379093+0100 kernel Sandbox: bash(4555) System Policy: deny(1) file-read-data /Users/user/Desktop/cronjob.sh
In the examples above
cron wasn't added to the Full Disk Access group.
cronjob2 was run from an unprotected folder ~/bin but tries to write the log file to the protected folder ~/Desktop/test/. So no read error but a write error.
cronjob was run from a protected folder ~/Desktop and tries to write the log file to the protected folder ~/Desktop/. So a read error.
Interestingly both log files are created - the first one (cronjob2.log) is empty though.