After reading John Gruber’s comments on why ‘Repair Permissions’ does not need to be run unless you actually have a permissions problem, I decided to repair permissions on my iMac anyway – just for the fun of it. :-)
To my surprise, Disk Utility reported that one file did not have the correct permissions and was thus repaired.
Permissions differ on ./private/var/log/secure.log, should be -rw------- , they are -rw-r-----
Owner and group corrected on ./private/var/log/secure.log
Permissions corrected on ./private/var/log/secure.log
What happened here? Had someone hacked into my system and adjusted permissions to make monitoring my activity easier? No, nothing quite as alarming as that. I had recently run the /etc/periodic/weekly/500.weekly script from the Terminal with the sudo periodic weekly command and now discovered that this script accidently grants additional permissions to the secure.log file with the log files are rotated.
This is not a real security risk since the additional permissions simply allow users in the admin group to have read access to the secure.log file, something they could usually do anyway with little effort.
I reported the problem to Apple and hopefully they will fix it in a future release. For now, I have applied this patch to the /etc/periodic/weekly/500.weekly script on my system to ensure the permissions for the secure.log file stay how they should be. Now I really have no reason to use Repair Permissions. :-)