cronie: vixie-cron, still maintained, with PAM and SELinux

A daemon everyone inherits without choosing

The README describes Cronie as containing the standard UNIX daemon crond that runs specified programs at scheduled times and related tools, with the source based on the original vixie-cron and carrying security and configuration enhancements such as the ability to use PAM and SELinux.

That lineage is the whole story of the project. Vixie cron was the implementation that every Linux distribution inherited in the 1990s, and for most of the following two decades the answer to new problems was to patch it locally. Cronie is the upstream that those patches eventually converged into, and the README's distribution list reads like a map of who took that step: Fedora, Mandriva, Gentoo, Source Mage, openSUSE, Arch Linux and Void Linux all package it.

Two of the related tools come with it. Anacron is the companion for jobs that should run when the machine was not powered on, and it has its own directory, its own licence file and its own release notes, and in the 1.5 series it became built by default. And cronnext is a utility that computes when a job would next run, which the 1.5.5 notes extend with the ability to select jobs by substring.

So the scope is a small, careful family of tools rather than a scheduler, and the primary language is C. The licence is one GitHub cannot classify, with a COPYING file at the repository root, and the source is downloadable from the project's releases.

The 1.7 line is about mail headers and exit status

The most recent releases, and the most recent one is 1.7.2 from 2024-04-08, are small and specific.

Release 1.7.2 contains two crond changes. One reverts the setting of the return path to `<>`, on the grounds that it is not RFC compliant, and the other has crond inherit MAILFROM from the crond process environment.

Release 1.7.1 has three items:

- crond: Wait on finishing the job with -n option to check
  the exit status
- crond: Do not set the return path to <> if non-default MAILFROM is set
- /etc/sysconfig/crond and /etc/default/anacron files are optional

That first line is a behaviour change rather than a fix. Waiting for a job to finish before checking its exit status changes what a wrapper script around a job can observe, and it is the kind of change that breaks a monitoring system which assumed crond did not wait.

The second is the other half of the 1.7.2 revert, and the third makes two configuration files optional rather than required, which is a distribution packaging concern that ends up in the release notes because every distribution that ships cronie has to care about it.

1.7.0 and 1.6.0 changed the crontab language itself

Release 1.7.0, from 2023-10-13, is the most feature-heavy of the recent releases:

- anacron: Add support for NO_MAIL_OUTPUT environment variable
- anacron: Support enabling anacron jobs on battery power
- crond: Support -n crontab entry option to disable mailing the output
- crontab: Make a backup of the crontab file on edition and deletion

The `-n` crontab entry option lets a single job suppress mailing its output, and the crontab backup on edition and deletion is a small safety net for the case where a bad edit destroys a crontab.

Release 1.6.0, from earlier in 2023, added a switch `-f` as an alias for `-n`, the random within range `~` operator, the use of the configure runstatedir directory for the pid file, and an increase of the maximum number of crontab entries to 10000. Release 1.6.1 then fixed a regression in the handling of ranges, the `x-y` form, in a crontab.

The `~` operator and the entry limit are the two changes that matter most to a user, because they change what a crontab can express. A 10000 entry limit is generous by any historical standard, and a random offset within a range is the kind of feature that only makes sense if you understand it.

1.5.x tightened the input and fixed anacron

The 1.5 series is where the parser hardening happened, and the release notes read like a security review.

In 1.5.5 the range and step validation was tightened, to explicitly validate the upper end of a range and the step so as to disallow entries such as `1-234/5678 * * * * ....`. That is a crond refusing to run a job whose specification is nonsense, which is exactly the shape of a denial-of-service fix. The same release made crond report a missing newline before end of file in syslog, so that the line is not completely silently ignored, and switched crontab colouring off when NO_COLOR is set, and made anacron built by default, and used a non-recursive build.

In 1.5.6 crontab without arguments began to work when stdin is not a TTY, a new option appeared to test a crontab file's syntax without installing it, and crond had various issues fixed around loading the crontab databases on startup.

In 1.5.7 anacron was fixed for the problem of not being started on some desktops, and crontab learned to switch off colours if NO_COLOR is set.

The 1.5.6 change is the one worth pausing on, because a syntax check that does not install the file changes crontab from a tool you run at the root prompt into something safe to run against a file you are editing, and that is a change to the workflow rather than to the code.

The 2019 CVEs and the regression that followed

Release 1.5.3 is the security release, and it shows what the project is for:

- Fix CVE-2019-9704 and CVE-2019-9705 to avoid local DoS of the crond.
- crontab: Make crontab without arguments fail.
- crond: In PAM configuration include system-auth instead of password-auth.
- crond: In the systemd service file restart crond if it fails.
- crond: Use the role from the crond context for system job contexts.
- Multiple small cleanups and fixes.

Two local denial-of-service issues in the daemon, the PAM stack switched from password-auth to system-auth so that a failed authentication follows the system policy, and the systemd unit now restarts crond if it fails.

Then there is the release note that is a warning rather than a fix. Release 1.5.4 says it fixes a regression from the previous release, where only the first job from a crontab was being run. A security release that broke the core function of the program, and then a follow-up release, is a realistic picture of what maintaining a foundational daemon looks like, and it is a better argument for the project continuing to exist than any feature list would be.

The line about using the role from the crond context for system job contexts is the SELinux side of the same story, and it connects back to the README's claim that the project carries the ability to use PAM and SELinux.

A conventional autotools tree with distribution packaging inside

The repository layout is what you would expect for a C daemon that seven distributions package, and it shows the shape of the work.

The build is autotools. There is `configure.ac`, a `Makefile.am`, an `autogen.sh` and an `INSTALL` file, plus a `contrib/` directory. The source lives in `src/`, and the anacron implementation is in its own `anacron/` directory with its own `README.anacron` and its own `COPYING.anacron`. The PAM integration is in `pam/`, the manual pages in `man/`, and the `obstack/` directory holds the memory allocation library the code uses, with its own `COPYING.obstack`.

The distribution-facing files are in the root. `cronie.spec` is the RPM spec file, `cronie.init` is the SysV init script, and `crond.sysconfig` is the configuration file for the daemon. `crond`, `crontab` and `anacron` are the user-visible programs.

The project metadata is interesting for a project of this age. There is a `.packit.yaml`, which is the configuration for Packit, the tool that automates downstream distribution work from an upstream git repository, and a `.github` directory. That is a modern touch on a codebase whose origins are in the 1990s, and it is the mechanism by which the fixes in the release notes actually reach the distributions that package cronie.

Contact is by mailing list, `cronie-devel` at the Fedora hosted lists, and bugs go to the GitHub issue tracker of the project.

Editorial conclusion

Cronie is the right thing to reach for when a system needs a cron implementation that still gets security work, since it is packaged by Fedora, Arch, openSUSE, Gentoo, Void and others and is the ancestor of most modern cron packages. It is the wrong choice if you want a scheduler with dependencies, job queues or observability, because crond is still a crontab runner and nothing more. Verify first which version your distribution ships, since the 1.6 and 1.7 lines fixed real parsing and mail behaviour changes, and read the release notes for the version you are moving from, because several of them alter what a crontab means rather than just adding features.

Frequently asked questions

Official sources

1. cronie-crond/cronie on GitHub
2. Issues
3. README
4. Releases