ansible-collection-hardening
ansible-collection-hardening copied to clipboard
getent_shadow empty
Description
Running os_hardening again Ubuntu 24.04 (on Pi5).
Reproduction steps
...
Run a playbook much like this:
- name: "Roles which apply to all hosts."
hosts:
- all
roles:
- name: Harden Operating System
role: devsec.hardening.os_hardening
with a requirements.yml like this:
---
collections:
- source: ../collection
type: dir
- name: devsec.hardening
version: 10.0.0
Current Behavior
TASK [devsec.hardening.os_hardening : Lock passwords from linux system accounts] ***
task path: /github/home/.ansible/collections/ansible_collections/devsec/hardening/roles/os_hardening/tasks/user_accounts.yml:92
fatal: [knuth]: FAILED! => {
"msg": "The conditional check 'getent_shadow[item][0] is not match(\"\\!\")' failed. The error was: error while evaluating conditional (getent_shadow[item][0] is not match(\"\\!\")): 'dict object' has no attribute 'daemon'. 'dict object' has no attribute 'daemon'\n\nThe error appears to be in '/github/home/.ansible/collections/ansible_collections/devsec/hardening/roles/os_hardening/tasks/user_accounts.yml': line 92, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Lock passwords from linux system accounts\n ^ here\n"
Expected Behavior
The task to succeed
OS / Environment
Ubuntu 24.04 arm64
Ansible Version
ansible [core 2.16.5]
config file = None
configured module search path = ['/home/vscode/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /home/vscode/.venv/lib/python3.12/site-packages/ansible
ansible collection location = /home/vscode/.ansible/collections:/usr/share/ansible/collections
executable location = /home/vscode/.venv/bin/ansible
python version = 3.12.2 (main, Feb 25 2024, 16:35:05) [GCC 11.4.0] (/home/vscode/.venv/bin/python3.12)
jinja version = 3.1.3
libyaml = True
Collection Version
10.0.0
Additional information
I can't find anywhere in the role that getent_shadow is populated, and its showing up in -vvv as blank:
TASK [devsec.hardening.os_hardening : Read local linux shadow database] ********
task path: /github/home/.ansible/collections/ansible_collections/devsec/hardening/roles/os_hardening/tasks/user_accounts.yml:10
Using module file /home/vscode/.venv/lib/python3.12/site-packages/ansible/modules/getent.py
Pipelining is enabled.
<mi-0c203fc0005c2f9d1> ESTABLISH SSH CONNECTION FOR USER: ha
<mi-0c203fc0005c2f9d1> SSH: EXEC ssh -o StrictHostKeyChecking=no -o ControlMaster=auto -o ControlPersist=60s -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o 'User="ha"' -o ConnectTimeout=10 -o 'ControlPath="/github/home/.ansible/cp/8b20310bef"' mi-0c203fc0005c2f9d1 '/bin/sh -c '"'"'/usr/bin/python3 && sleep 0'"'"''
<mi-0c203fc0005c2f9d1> (0, b'\n{"ansible_facts": {"getent_shadow": {}}, "invocation": {"module_args": {"database": "shadow", "fail_key": true, "key": null, "service": null, "split": null}}}\n', b'')
ok: [knuth] => {
"ansible_facts": {
"getent_shadow": {}
},
"changed": false,
"invocation": {
"module_args": {
"database": "shadow",
"fail_key": true,
"key": null,
"service": null,
"split": null
}
}
}
If i run ansible knuth -m ansible.builtin.getent -i ansible/inventory/ -a "database=shadow" then I get an empty response as we're seeing here:
knuth | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3",
"getent_shadow": {}
},
"changed": false
}
However if I run ansible knuth -m ansible.builtin.getent -i ansible/inventory/ -a "database=shadow" -b (note the -b) then I get a populated output:
ok as none of the tasks in os_hardening are marked as become: true I guess the design intent is that it is run with become: true
Woudl you welcome a PR to update the example playbook?
- hosts: all
roles:
- name: devsec.hardening.os_hardening
Sure thing! You need to update it here, though: https://github.com/dev-sec/ansible-collection-hardening/blob/683706a024bea18a304a81186f26132eab20ef9a/.aar_doc.yml#L45, as we automatically generate the Readme.
I hit this issue as well while testing this role in --check mode.