Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 09 Jan 2025 19:00:32 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 283964] cron processing logic flawed with cron.d configs
Message-ID:  <bug-283964-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283964

            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=3D256589&action=
=3Dedit
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 thou=
gh
it should only be running jobs b and c.

The problem seems to be with the implementation of the cron.d parsing and i=
ts
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 additi=
on
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 ne=
xt
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.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283964-227>