Cron is fussy about its permissions

Index, feed.

Summary: because of my ignorance of cron's finickiness about file permissions on crontab files, I ended up accidentally disabling root's scheduled jobs.

1. I wanted to keep a version history of root's crontab, but wanted the versioning process to run as a separate user. I though it would be a good idea to have root's crontab include the following:

   * * * * * chmod a+r /var/spool/cron/crontabs/root

2. this actually worked in initial testing: root's new crontab would be in effect, and, after the beginning of the next minute, other users would be able to read and backup the file...

3. until some other user edited their own crontab: then root's jobs would stop being run! I would then eventually notice, tweak things in root's crontab, and things would be back to normal, until the next edit of any other user's crontab;

4. after a few of those annoying cycles, I decided to try finding out what was going on, read the logs, and saw this happening after non-root crontab edits (irrelevant bits elided):

   (root) INSECURE MODE (mode 0600 expected) (crontabs/root)

   On the other hand, root crontab edits would appear successful at first:

   (root) BEGIN EDIT (root)
   (root) REPLACE (root)
   (root) END EDIT (root)

   Indeed, just after running crontab -e, file permissions would be correct; it is only after the chmod job has run once that the permissions are checked, but cron only checks for those upon reload, by any user, which could be much later.

   That was surprising. I now leave permissions alone and instead run:

   * * * * * cp -u --no-preserve=mode /var/spool/cron/crontabs/root /tmp/c

   Presumably, this is cheap, as metadata for the source file is likely to be kept in cache, and the target file is on tmpfs.

www.kurokatta.org

David Haguenauer <www@kurokatta.org>
$Id: cron-perms.malblog,v 1.5 2018/09/02 04:10:10 homer Exp $