Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 128701 - cron misinterprets files in /etc/cron.d
cron misinterprets files in /etc/cron.d
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-28 07:58 EDT by Ralf Ertzinger
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-30 14:45:16 EDT
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 Ralf Ertzinger 2004-07-28 07:58:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040625

Description of problem:
/etc/cron.d contains one file (sysstat, owned by the sysstat package)

It contains, among others, a line like
*/10 * * * * root /usr/lib/sa/sa1 1 1

According to the man page for cron, this format is correct for the
/etc/crontab file and files in /etc/cron.d. However, cron seems to
interpret the file like user crontab files, using everything from the
sixth field on as the command to be executed, so it ends up trying to
execute a command called "root" (which does not exist, of course).

Because of this cron sends a mail about this every ten minutes.

Version-Release number of selected component (if applicable):
vixie-cron-4.1-1

How reproducible:
Always

Steps to Reproduce:
1. Upgrade to cron 4.1 and have files in /etc/cron.d
2. Wait for execution of one in these files
3.
    

Actual Results:  cron treats the user name as commmand to be executed

Expected Results:  Execution of the program as the user specified

Additional info:
Comment 1 Jason Vas Dias 2004-07-28 11:06:38 EDT
Whoops! Sorry...
Yes, the patch to read in /etc/cron.d appears to have been misapplied
and incorrectly ran those crontabs as "user" crontabs.

This is now fixed ( vixie-cron-4.1-3 ) .
Comment 2 Ralf Ertzinger 2004-07-30 18:12:39 EDT
Something is still fishy with vixie-cron-4.1-4.
Every ten minutes I get the following in the syslog file:

crond[xxxx]: Critical error - immediate abort

The only possible culprit is the file in /etc/cron.d
Comment 3 Jason Vas Dias 2004-07-30 18:18:27 EDT
Actually, the "immediate abort" is the subject of bug 128843,
which was fixed today in vixie-cron-4.1-6 -
you need to add the line:
    auth sufficient pam_rootok.so
to the /etc/pam.d/cron.d file
(or install vixie-cron-4.1-6) - also
it's best to install pam-0.77-53.
Comment 4 Nils Philippsen 2004-08-18 07:07:42 EDT
FYI: Same here with vixie-cron-4.1-FC2_1 on FC2, I'll downgrade for
the time being.
Comment 5 Jason Vas Dias 2004-08-18 09:12:59 EDT
 There are no known problems with vixie-cron-4.1-FC2_1 on FC2 -
 this bug is closed.
 ISC vixie-cron-4.1 has tightened security restrictions on crontab 
 files:
  o they must not be writable by any user other than root
  o they must not be links
 But lines like:
  */10 * * * * root /usr/lib/sa/sa1 1 1
 work fine, and the "immediate abort" bug is also fixed, but also
 only happened with FC3/rawhide systems where selinux is enabled.
Comment 6 Jason Vas Dias 2004-08-18 09:36:46 EDT
 Oh dear - it seems the fix for this bug got dropped when I removed
 the selinux stuff for the FC2 release - sorry! I'm now generating
 vixie-cron-4.1-FC2-2 .
Comment 7 Jason Vas Dias 2004-08-18 10:19:23 EDT
 This is now fixed in vixie-cron-4.1-FC2-2 .

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