Bug 142953
Summary: | Cron no longer allows read-only crontabs, enforces write access | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Nigel Metheringham <nigel> |
Component: | vixie-cron | Assignee: | Jason Vas Dias <jvdias> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | tao |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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 19:56:47 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163881 |
Description
Nigel Metheringham
2004-12-15 11:57:54 UTC
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. *** |