Bug 130102 - users can no longer use crontab by default?
Summary: users can no longer use crontab by default?
Alias: None
Product: Fedora
Classification: Fedora
Component: vixie-cron
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: Brock Organ
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
Reported: 2004-08-17 02:39 UTC by Jens Petersen
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version: vixie-cron-4.1-14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-09-29 14:49:58 UTC

Attachments (Terms of Use)

Description Jens Petersen 2004-08-17 02:39:24 UTC
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):

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?

Comment 1 Jason Vas Dias 2004-08-18 15:13:46 UTC
 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
 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 
 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 
 This new behaviour is also more in line with increased security 
 across all Linux utilities generally. 

Comment 2 Bill Nottingham 2004-08-18 15:51:28 UTC
Reopening; this is a regression of behavior from previous releases,
and means on upgrades that people can't edit their own crontabs.

Comment 3 Jason Vas Dias 2004-08-18 17:33:32 UTC
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 .

Comment 4 Milan Kerslager 2004-08-23 07:53:05 UTC
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

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

Comment 5 Jason Vas Dias 2004-08-23 14:24:02 UTC
Files /etc/cron.allow and /etc/cron.deny ARE an integral part of

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 .

Comment 6 Milan Kerslager 2004-08-23 15:08:49 UTC
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.

Comment 7 Jason Vas Dias 2004-08-23 17:49:34 UTC
OK, /etc/pam.d/crond will be marked as noreplace.

Comment 8 Jens Petersen 2004-09-29 05:40:38 UTC
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...

Comment 9 Jason Vas Dias 2004-09-29 14:49:58 UTC
 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 .


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