Who May Schedule Work, And The Crontabs That Outlive The Answer

cron-access

Every account on an EL host may schedule work. cronie ships an empty /etc/cron.deny and no /etc/cron.allow, and at does the same, so the default is that anyone who can log in can arrange to run something later. This role writes the allow list for both schedulers - and then deals with the part that catches people out: the access check is in the crontab command, so a crontab installed before the policy arrived keeps running afterwards.

No download, and no version to pin. cronie and at are EL 10 packages. What the role owns is the two allow files, the state of crond, and the spools of accounts that may no longer schedule.

An allow file makes the deny file irrelevant. Once /etc/cron.allow exists, cron.deny is not consulted at all - measured with an account named in both, which was allowed. The role writes the allow file and leaves the empty cron.deny the distribution ships where it is, since editing it would change nothing.

The access check is in crontab, not in crond. An account removed from the allow list can no longer list, edit or install a crontab - "You (x) are not allowed to use this program (crontab)" - but the crontab it installed earlier goes on running. Measured across a crond restart: the job ran at 10:55 with no policy, and ran again at 10:56 with the policy in force. What stopped it was removing the spool file. So cron_access_clear_denied_spools is on by default, and the live test proves both halves - the command is refused, and the job that was demonstrably running before the role ran does not run again in the minute after it.

Both of crontab's answers exit non-zero. "not allowed" and "no crontab for x" are both exit code 1, so a test that reads the exit code cannot tell a refused account from an allowed one with nothing scheduled. This test reads the message. That is also how it gets a control: the same account is asked again with its name added to the file the role wrote, has to get "no crontab for", and the file is then put back - which proves the refusal came from this policy and not from a broken su, an unusable account or a missing cronie.

crontab -r -u rather than deleting the spool file. cronie keeps a copy of a crontab it removes, under /root/.cache/crontab/, so an operator who finds the policy too broad has the content back. A spool file whose name matches no account on the host is left alone: crontab -r -u refuses an unknown user, and a crontab crond will never run is worth reporting rather than quietly deleting.

at is a second scheduler with the same default. The at package ships an at.deny holding nothing, so the same host that restricts cron can still have work queued through at. The role writes /etc/at.allow as well; a denied account gets "You do not have permission to use at." The atd unit is left as the distribution has it, because the access check is in the client.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.