Bug 142953 - Cron no longer allows read-only crontabs, enforces write access
Cron no longer allows read-only crontabs, enforces write access
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks: 163881
  Show dependency treegraph
 
Reported: 2004-12-15 06:57 EST by Nigel Metheringham
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: vixie-cron-4.1-20_EL3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-14 14:56:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nigel Metheringham 2004-12-15 06:57:54 EST
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:
Comment 1 Jason Vas Dias 2004-12-15 11:48:06 EST
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. 
Comment 2 Jason Vas Dias 2004-12-15 12:03:17 EST
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.
Comment 3 Nigel Metheringham 2004-12-15 12:24:11 EST
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.
Comment 4 Jason Vas Dias 2005-01-14 14:56:47 EST
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.
Comment 5 Jason Vas Dias 2005-05-25 09:48:49 EDT
*** Bug 158746 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.