[Bug 283964] cron processing logic flawed with cron.d configs

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283964

            Bug ID: 283964
           Summary: cron processing logic flawed with cron.d configs
           Product: Base System
           Version: 14.2-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: matthew.l.dailey@dartmouth.edu

Created attachment 256589
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256589&action=edit
Potential patch

The way that cron processes crontabs in cron.d is flawed such that jobs can be
duplicated, old jobs can continue to run after a file is deleted, and jobs can
be skipped entirely.

The easiest way to illustrate is to create three cron jobs:
echo "*/1 * * * * root /usr/bin/true a" > /etc/cron.d/a.conf
echo "*/1 * * * * root /usr/bin/true b" > /etc/cron.d/b.conf
echo "*/1 * * * * root /usr/bin/true c" > /etc/cron.d/c.conf

Touch the files so they all have identical timestamps:
touch /etc/cron.d/a.conf /etc/cron.d/b.conf /etc/cron.d/c.conf

Start cron and/or let it run for more than a minute to verify all three jobs
run.

Remove a.conf:
rm /etc/cron.d/a.conf

At this point, cron will continue to run jobs a and b and skip c, even though
it should only be running jobs b and c.

The problem seems to be with the implementation of the cron.d parsing and its
interaction with find_user(). Vixie cron has no notion of cron.d, so the
internal database expects a single entry for each user. However, the addition
of cron.d logic adds additional "*system* entries in the database for each of
the files in cron.d. find_user() simply then advances the pointer to the next
entry for this user, regardless of which cron.d file is being processed. If the
mtime of this matches the entry in the old database, it is copied over with
potentially incorrect data.

I've attached a possible fix for this that works in limited testing, adding the
actual filename to the internal database and using this, along with the
username for lookup. One disadvantage of this approach is that it takes the
code further away from Vixie cron. An alternate solution would be to append
additional crontabs from cron.d to the existing "*system" entry in the
database, but this would be a much more substantial change.

-- 
You are receiving this mail because:
You are the assignee for the bug.