Description of problem: In previous releases of FC it was possible to have r/o crontab files, for example an rpm which needs cron entries might drop a file into /etc/cron.d/my-package which was mode 444 or similar. This no longer works - the check in database.c around line 260 has the following code:- if ((statbuf->st_mode & 07733) != 0600) { log_it(fname, getpid(), "BAD FILE MODE", tabname); goto next_crontab; } which *enforces* the owner write bit. Although it may not be good practice to make these r/o (I would be prepared to argue this point), enforcing writability seems counter-intuitive, especially when you end up reading the damn source code to find out just what is wrong :-) Version-Release number of selected component (if applicable): vixie-cron-4.1-19 How reproducible: Every time Steps to Reproduce: 1. install -m444 mycrontab /etc/cron.d/mycrontab 2. look at output in /var/log/cron Additional info:
Yes, I suppose that should have been ((statbuf->st_mode & 07133) != 0) Previously, the default ISC cron 4.1 was doing : ((statbuf->st_mode & 07777) != 0600) ie. ALL crontabs HAD to have mode 0600 to be loaded. This was judged too restrictive in not allowing group read. Now I guess you have a point that we should allow read-only crontabs - or perhaps take out all the mode enforcement altogether. The next version (vixie-cron-4.1-21) will not have this problem. Thanks for pointing it out.
Here's another suggestion for fixing this problem: We could add a '-m' "Mode Mask" option to crond. If -m is not set, then the default mode mask will be 07133, and the code will be changed to ((statbuf->st_mode & mode_mask) != 0) if -m is set to 0, then all modes will be allowed, and the code will not accept a mode of all ones or 07777, changing it to the default. Then crontab will also need a '-m' option, because it always creates crontabs using the default 'umask'. You should ALWAYS be using crontab to install crontab files, so you should in future be able to replace install -m444 mycrontab /etc/cron.d/mycrontab with crontab -m444 mycrontab (by default, crontab currently always makes the crontab file have mode 0600, so you could also have circumvented this problem by using 'crontab mycrontab' ). Ideas / suggestions welcome.
Comments in #2 are interesting - however needing to add -m to crontab would appear to make life more confusing for many people, and so might well increase support load.... My preference would be to not add more complexity here unless you have a particular requirement for it. BTW I don't see a way to make crontab install crontab-files into /etc/cron.d and it would make things more complex for me as the crontab in question is part of a rpm for a relatively complex package that runs as multiple UIDs (so just packaging a crontab as a file within /etc/cron.d/... with the cron commands for multiple (package defined) user accounts within it. In this case the other /etc/cron.{daily,...} classifications are inappropriate.
This is now fixed in vixie-cron-4.1-20_EL3, being pushed to FC3 updates by tomorrow. A) Cron will now allow read-only crontabs by default B) There is now a '-p' `permit all crontabs' option to disable the problematic mode checking code completely.
*** Bug 158746 has been marked as a duplicate of this bug. ***