[..Originally covered in Issue Tracker 116438..] Description of problem: Presently crond and crontab use completely separate means of authorization. This can lead to a situation where a user can create or manipulate their crontab that may not ever be permitted to execute. crontab uses /etc/cron.{allow,deny} exclusively, and crond uses PAM exclusively. While we can understand some cases where a user may be permitted to have a crontab but not edit it (/etc/cron.{deny,allow}), for example a daemon account whose crontab is manipulated by root, a user who isn't permitted to run a cronjob shouldn't be able to create one. This "silent" failure inevitably leads to confusion for both the user and admin. In our case, we populate access.conf in production to limit the users who may have crontabs, ie: -:ALL EXCEPT root :cron How reproducible: Steps to Reproduce: 1. Revoke user 'foo' access via PAM to cron (ie. access.conf) 2. User 'foo' edits crontab. 3. Crontab entries are never executed. Expected results: Prior to invoking editor, crontab (and perhaps atq) report: You (foo) are not allowed access to cron, crontab entries will not be executed. While a pause-for-acknowledgment would seem to make the most sense, this could break automated maintenance of crontabs, so perhaps requiring a "-f" flag would be the safest means. Additional info: It'd be great to see documentation updated to emphasize that cron.deny and cron.allow are really "crontab.deny" and "crontab.allow" and have no effect on the operation of cron. Calling this out explicitly would hopefully correct a common misconception.
I need more information about problem. Could you tell me version of vixie-cron, crontab, pam and which rhel do you have?
re comment 1 -- opened this specifically against RHEL4 (so for completeness, we'll say vixie-cron 4.1-44.EL4 and pam 0.77-66.17), but versions are largely irrelevant as the same applies to RHEL3 or RHEL5.
Marcela -- do you require any further details?
*** Bug 248459 has been marked as a duplicate of this bug. ***
No, thanks, now I have enough information. You're right, the problem is even on RHEL-5, but not the exactly same. I'm working on fix for both RHEL, it will be available in next update.
vixie-cron-4.1-83.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
Comment #8 is only for Fedora 7. This fix should be included in next release.
vixie-cron-4.1-83.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
Bug wasn't fixed for RHEL-4.7, patch is ready.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
*** This bug has been marked as a duplicate of bug 249512 ***
Jeremy West 249512 is not generally visible ... could you please summarize, or clone into an open form that prior bug
This is CLOSED/WONT but a dupe of 249512? To followup to comment 30, could someone clarify the disposition of that bug?
The product management and development management agreed that due to significant differences between pam in RHEL4 and RHEL5 and due to RHEL4 state where we are targeting only performance issues and security issues for 4.9. This is still considered for RHEL5 (via the bug you are referencing)