sudo, A Policy Checked Before It Lands, Refusals Proven
A sudo policy on EL 10 as a drop-in that visudo checks before it lands, with commands written out with their arguments. The live test runs the allowed command without a password and is refused three ways: another subcommand, the same command with a different argument, and a user outside the group. Both appear in sudo's own log. 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-26 · 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-sudoers-policy?utm_source=syndication&utm_medium=readme&utm_campaign=artifact)
Ansible role 1.0.0, live-tested on IaC Bazaar: [sudo, A Policy Checked Before It Lands, Refusals Proven](https://www.iac-bazaar.com/catalog/ansible-sudoers-policy?utm_source=syndication&utm_medium=readme&utm_campaign=artifact)
```yaml
# sudo, A Policy Checked Before It Lands, Refusals Proven: https://www.iac-bazaar.com/catalog/ansible-sudoers-policy (download from your IaC Bazaar account)
```Preview:
Documentation
sudoers-policy
Who may run what, as a file sudo will accept. The role writes one drop-in
under /etc/sudoers.d, checked by visudo against the rendered candidate
before it lands, with the mode and ownership sudo demands. Commands are written
with their arguments, so the policy grants exactly what it says.
No download, and no version to pin. sudo is part of EL 10, so the role
installs it by name and takes what the distribution ships. What the role owns
is the policy and the proof that the host obeys it - in both directions, which
for an access rule is the only test worth having.
Nothing to reload. sudo reads the policy on every invocation, so there is no service to restart and no window in which the old policy is still in force. That is also why this role has no handlers at all.
The mode is function, not hygiene, and only visudo -c sees it. A drop-in
left at 0644 still works - sudo reads it and the allowed command runs - while
visudo -c reports "bad permissions, should be mode 0440". A file owned by
anyone but root is worse: sudo ignores the policy and falls back to asking for a
password. The verify therefore asserts both the behaviour and visudo -c,
because either one alone passes a host whose policy is quietly broken.
requiretty is not set. With it, every automated caller fails with "you
must have a tty" - including Ansible, and including this role's own live test.
It is a common hardening recommendation and it breaks the thing it is applied
to.
sudo -l exits 0 for a user with no rules at all, so the live test reads
its output rather than its exit code.
A refused command says "a password is required", not "not allowed". Because
every rule here is NOPASSWD and the policy carries no blanket !authenticate,
sudo tries to authenticate a command outside the list before deciding it is not
permitted - so under sudo -n the message names the password, not the policy.
Adding !authenticate would make the message accurate and would also make any
password-requiring rule added later silently passwordless, which is the worse
trade. The live test therefore reads the OUTCOME rather than the message: the
refused command produces no output at all.
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-lynis
Lynis from EPEL on a systemd timer, with the units the package keeps only in its docs, your skipped tests in custom.prf, and a minimum hardening index below which the audit unit fails, so a falling score shows as a failed unit. The live test runs the audit, reads the index and the tests that ran, and finds the timer enabled. Original role, live-tested on Rocky Linux 10.
ansible-suricata
Suricata from EPEL watching the default-route interface as the suricata user, ET Open fetched at install and refreshed daily, plus a canary rule that proves the sensor is alive. A root-run check left root-owned logs and a daemon recording nothing; the role prevents it. The live test raises the canary alert while a second lookup is logged, not alerted. Original role, live-tested on Rocky Linux 10.
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-389-ds
389 Directory Server from AppStream. A fresh instance listens on every interface and lets anonymous clients read the tree; this role binds both listeners to loopback and limits anonymous clients to the rootDSE. The live test adds a user who binds, sees a wrong password and an anonymous search refused, and reads the LDAPS certificate. Original role, live-tested on Rocky Linux 10.
ansible-krb5-kdc
An MIT Kerberos KDC: the realm created once with a stash, kadmind behind an ACL, a default policy that locks an account after five wrong passwords, every listener on loopback. The KDC starts on a broken config without a word, so the live test proves each setting by behaviour: the ticket lifetime, the refusals, the lockout. 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.