Bug 130102
| Summary: | users can no longer use crontab by default? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jens Petersen <petersen> |
| Component: | vixie-cron | Assignee: | Jason Vas Dias <jvdias> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | milan.kerslager, notting, redhat-bugzilla |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | vixie-cron-4.1-14 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-09-29 14:49:58 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: | 123268 | ||
The old default behaviour (allowing any user to create crontabs) can be restored by simply creating an empty /etc/cron.deny: # touch /etc/cron.deny Users could then use /etc/security/limits.conf to control cron access. Now that the current default behaviour agrees with the documentation, from crontab(1): " If the cron.allow file exists, then you must be listed therein in order to be allowed to use this command. If the cron.allow file does not exist but the cron.deny file does exist, then you must not be listed in the cron.deny file in order to use this command. If neither of these files exists, only the super user will be allowed to use this command. " I don't think we should undo the corrected behaviour of the new implementation. If we were to make crontab allow all users if no files existed, then in order to get the current default behaviour (no non-root users allowed to edit crontab) one would have to list all users in /etc/cron.deny. This new behaviour is also more in line with increased security across all Linux utilities generally. Reopening; this is a regression of behavior from previous releases, and means on upgrades that people can't edit their own crontabs. OK, if neither /etc/cron.allow nor /etc/cron.deny exist at install, the %post script will touch /etc/cron.deny, thus restoring previous default crontab behaviour. fixed in version: vixie-cron-4.1-10 . Files /etc/cron.allow nor /etc/cron.deny are not a part of the package. Instead of ugly %post script include this to %install touch $RPM_BUILD_ROOT/etc/cron.allow cat > $RPM_BUILD_ROOT/etc/cron.deny <<EOF # /etc/cron.deny - this file contains list of users not allowed # to use crontab command # # see the crontab(1) manual page for more info EOF And this to %files: %config(noreplace) /etc/cron.deny %config(noreplace missingok) /etc/cron.allow The second problem is that /etc/pam.d/crond is not marked as noreplace so every change is lost after upgrade (especially uncommented PAM support for cron). So change the %files line like this: %config(noreplace) /etc/pam.d/crond Files /etc/cron.allow and /etc/cron.deny ARE an integral part of vixie-cron. The point of this bug was to restore the default behaviour of previous RedHat vixie-cron: all users are allowed to edit crontabs by default. This will only be allowed if no cron.allow exists and cron.deny is empty. The .spec file patch you suggest would have the opposite effect, denying all users except root the ability to edit crontabs - hence the patch is rejected. /etc/pam.d/crond is part of the vixie-cron package, and may need to be replaced by an install - one serious bug has already been fixed by replacing it - hence, it will remain a %config file, and not a %config(noreplace) file . The files are not a part of the package. Try on your package this: rpm -qlp vixie-cron-4.1-10.i386.rpm You are right - I forget to include %ghost before /etc/cron.allow. I tryed upgrade mode on different situation and all went ok (since I have %ghost in my package). To not mark config file /etc/pam.d/crond as noreplace is wrong because user modifications are lost after update. If there was a bug in /etc/pam.d/crond and you will made another package with modified /etc/pam.d/crond, the rpm utility will replace the file silently if the user has not changed old /etc/pam.d/crond. If the user has changed /etc/pam.d/crond (with the bug inside) the rpm will create new /etc/pam.d/crond.rpmnew, complain and the user should resolve this change by itself like in another cases (where syntax of the new config file has been changed for example). So you are really wrong to not mark this file as noreplace and this is a serious bug. OK, /etc/pam.d/crond will be marked as noreplace. The original issue seems to be back. I'm testing with vixie-cron-4.1-12. It seems this was reverted in pkg cvs without any comment... Aargh! Yes, somehow the changes applied to vixie-cron-4.1-10 got dropped - it seems cvs thought the latest version was vixie-cron-4.1-9 . I've re-applied them and they are in vixie-cron-4.1-14 . |
Description of problem: Reading crontab(1) it seems this is the intended behaviour, but I noticed that crontab is not longer allowed to be run by normal users on a default installation, whereas previously this was allowed in contradiction to the documentation. Version-Release number of selected component (if applicable): vixie-cron-4.1 How reproducible: every time Steps to Reproduce: % crontab -l Actual results: You (petersen) are not allowed to use this program (crontab) See crontab(1) for more information Expected results: I guess the new behaviour is correct, but perhaps empty /etc/cron.{allow,deny} could be added to restore the old behaviour, but should they?