Bug 178436

Description of problem:

During errata QA testing of vixie-cron-4.1-8.EL3, it was found that in 4 days
of running crond, bug 159800 could occur ( the same per-minute job could be
run more than once per minute ) if the initgroups() call done in the job
process is delayed, eg. by an interruption in network service if the 
/etc/nsswitch.conf file contained a network lookup method for the groups
database.

When a run of a job to be run every minute is delayed for more than one minute
by authentication / setuid / setgid / initgroups, crond should skip that run
of the per-minute job.

Here's an example of this happening during QA testing of errata RHSA-2006:0117:

crond performs these steps when running a job:

1. Forks "minder" process, which opens the PAM session, and PAM emits messages
of the form:

   Jan 13 21:22:01 bender crond(pam_unix)[26072]: session opened for user root
by (uid=0)

   to /var/log/messages

2. "minder" process forks the "job" process, which performs the LAuS logging (if
LAuS is enabled),
   and then emits a message of the form:

   Jan 13 21:22:01 bender crond[26073]: (root) CMD (/bin/date +%s >>
/tmp/159800.test.log)

   to /var/log/cron .

3. "job" process does  'setgid(...);  initgroups(); ... setuid(...);' and then
execve()s the job command.

4. "minder" process waits for "job" process to exit, and then closes the PAM
session, which makes PAM
   emit messages of the form:

   Jan 13 21:25:10 bender crond(pam_unix)[26072]: session closed for user root

   to /var/log/messages.

As shown with the messages above, when the failure occurs, a job that reaches
step (2) in one minute, is delayed
for more than a minute before the execve() is done - so it must be the
    'setgid(...);  initgroups(); ... setuid(...);'
that is potentially delaying the job for more than one minute.

All the jobs which fail to run in separate minutes complete Step(2) above at the
correct time:

 Failure 1:
 FAILED at line 860: 1137205474 (Fri Jan 13 21:24:34 2006) is in same minute as
1137205462 (Fri Jan 13 21:24:22 2006)

   Jan 13 21:23:01 bender crond(pam_unix)[26074]: session opened for user root
by (uid=0)
   Jan 13 21:23:01 bender crond[26075]: (root) CMD (/bin/date +%s >>
/tmp/159800.test.log)
   Jan 13 21:24:01 bender crond(pam_unix)[26076]: session opened for user root
by (uid=0)
   Jan 13 21:24:01 bender crond[26077]: (root) CMD (/bin/date +%s >>
/tmp/159800.test.log)
   (
       26077 job delayed by 21 seconds, and actually runs here, logging 1137205462
   )
   Jan 13 21:24:22 bender crond(pam_unix)[26076]: session closed for user root
   (
       26075 job delayed by 1min,23seconds, now runs, logging 1137205474
   )
   Jan 13 21:24:34 bender crond(pam_unix)[26074]: session closed for user root

   Times logged:
   Fri Jan 13 21:24:22 2006
   Fri Jan 13 21:24:34 2006

 Failure 2:
 FAILED at line 862: 1137205510 (Fri Jan 13 21:25:10 2006) is in same minute as
1137205501 (Fri Jan 13 21:25:01 2006)

   Jan 13 21:22:01 bender crond(pam_unix)[26072]: session opened for user root
by (uid=0)
   Jan 13 21:22:01 bender crond[26073]: (root) CMD (/bin/date +%s >>
/tmp/159800.test.log)
   (
       Meanwhile, Failure(1) occurs, and the job for 21:25 is scheduled and run
normally,
       as is the mrtg job
   )
   Jan 13 21:25:01 bender crond(pam_unix)[26090]: session opened for user root
by (uid=0)
   Jan 13 21:25:01 bender crond[26093]: (root) CMD (/bin/date +%s >>
/tmp/159800.test.log)
   Jan 13 21:25:02 bender crond(pam_unix)[26090]: session closed for user root
   (
       job 26073 actually runs here, and logs 1137205510 (Fri Jan 13 21:25:10
2006) -
       this job was meant to run at 21:22:01, but was delayed more than 3 minutes!
   )
   Jan 13 21:25:10 bender crond(pam_unix)[26072]: session closed for user root

   Times logged:
   Fri Jan 13 21:25:01 2006
   Fri Jan 13 21:25:10 2006


Version-Release number of selected component (if applicable):
vixie-cron-4.1-8.EL3

How reproducible:
Very rarely

Steps to Reproduce:
Make network authentication services time out during run of a cron job
  
Actual results:
A per-minute job is delayed into the next minute

Expected results:
A per-minute cron job that gets delayed into the next minute by network
timeouts should be skipped .