Who May Schedule Work, And The Crontabs That Outlive The Answer
cronie ships an empty cron.deny and no cron.allow, so every account may schedule work, and at is the same. This role writes both allow files and clears the spools of accounts that may no longer use them, because the access check is in the crontab command: a crontab installed earlier keeps running. The live test watches one run, then stop. Original role, live-tested on Rocky Linux 10.
Verification
Live-testedReally deployed to a container sandbox, proven idempotent (a second run changes nothing), verified against the role’s assertions, then torn down.
Conformance
- Static validation (yamllint · ansible-lint)
Provenance
- SHA-256 checksum
- Signature (pending)
Functional
- Live-tested - applied, verified, destroyed
Last verified 2026-09-27 · podman 4.9.3 · ansible 2.21.4 · how we verify
Cite it in your README
badge · attributionPaste this beside the module in the repository that uses it. The badge is rendered from this artifact's verification record, so it reads live-tested because the record says so, and the link lands on this page.
[](https://www.iac-bazaar.com/catalog/ansible-cron-access?utm_source=syndication&utm_medium=readme&utm_campaign=artifact)
Ansible role 1.0.0, live-tested on IaC Bazaar: [Who May Schedule Work, And The Crontabs That Outlive The Answer](https://www.iac-bazaar.com/catalog/ansible-cron-access?utm_source=syndication&utm_medium=readme&utm_campaign=artifact)
```yaml
# Who May Schedule Work, And The Crontabs That Outlive The Answer: https://www.iac-bazaar.com/catalog/ansible-cron-access (download from your IaC Bazaar account)
```Preview:
Documentation
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.
Usage code & full reference need an account
The complete copy-paste usage, the full input/output reference, and operational notes are free with an account - shown here and bundled in the download. Sign in and this section fills in.
- Variables
- Test
Related modules
ansible-aide
AIDE from AppStream on EL 10: a watched tree, a baseline database built once, and the oneshot unit and timer the package does not ship. The live test passes on an unchanged host, FAILS when a file appears inside a watched path and names it, ignores one inside an excluded path, and passes again once the change is gone. Original role, live-tested on Rocky Linux 10.
ansible-authelia
Authelia from the upstream release (sha256-verified) as a hardened system service on loopback with file users and sqlite; its secrets are generated once on the host and reach the service as AUTHELIA_*_FILE variables. The live test hashes a password with Authelia's hasher, logs in, sees a wrong password refused and an anonymous visitor sent to the portal. Original role, live-tested on Rocky 10.
ansible-bandit
bandit on EL 10 from PyPI into a venv of its own with a link in the PATH; the live test runs pip check, then scans a module that passes a string to subprocess.call with shell=True (B602, High, exit 1) and a clean module (exit 0). Pinned. Original role, live-tested on Rocky Linux 10.
ansible-boundary
boundary on EL 10 from releases.hashicorp.com; SHA256SUMS is signature-checked against HashiCorp's key before get_url trusts it, the live test re-checks both, then runs authenticate against a dead address ('connection refused') and database init with a throwaway config (parsed, root key loaded, then the database refused). Pinned. Original role, live-tested on Rocky Linux 10.
ansible-dockle
dockle on EL 10 from the GitHub release; get_url refuses it unless its SHA-256 is in the vendor's checksums file, and the live test re-checks it, then scans a one-layer image whose config names no user, expecting CIS-DI-0001 in the output, exit code 1 with --exit-level warn, and the warning counted in the JSON form. Pinned. Original role, live-tested on Rocky Linux 10.
ansible-gitleaks
gitleaks on EL 10 from the GitHub release, refused by Ansible's get_url unless its SHA-256 is the one in the project's checksums file, and re-checked with sha256sum -c by the live test, which then plants a file holding an AWS access key that is not one and runs gitleaks detect over it, expecting 'leaks found: 1'. Original role, live-tested on Rocky Linux 10.