You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When calling the role os_hardening passing the variable os_auth_retries defined in vars as part of include_role, some comparison guards in pam_debian.yml cause an exception. It appears that the variable passed via vars is a string, but the comparison guards expect an int without type casting it.
fatal: [instance]: FAILED! => {"msg": "The conditional check 'os_auth_retries > 0' failed. The error was: Unexpected templating type error occurred on ({% if os_auth_retries > 0 %} True {% else %} False {% endif %}): '>' not supported between instances of 'AnsibleUnsafeText' and 'int'\n\nThe error appears to be in '/home/user/.cache/ansible-compat/f22a9c/collections/ansible_collections/devsec/hardening/roles/os_hardening/tasks/pam_debian.yml': line 20, 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: Install tally2\n ^ here\n"}
According to some ansible upstream issues, the actual role code should be the one doing the type casting to the expected type, see e.g. ansible/ansible#13574 (comment)
Indeed, manually modifying the local checkout of the os_hardening role and modifying the entries to use the following does solve the problem:
when:
- os_auth_retries | int > 0
...
when:
- os_auth_retries | int > 0
...
when:
- os_auth_retries | int == 0
I could provide a patch but I'd just like to get first a heads-up about the approach. Thanks!
dlouzan
changed the title
os_auth_retries variable causes a comparison type error on pam_debian.yml
os_auth_retries variable causes a comparison type error on pam tasks
Oct 27, 2022
Describe the bug
When calling the role os_hardening passing the variable
os_auth_retries
defined invars
as part ofinclude_role
, some comparison guards inpam_debian.yml
cause an exception. It appears that the variable passed viavars
is a string, but the comparison guards expect an int without type casting it.Example case:
this produces:
According to some ansible upstream issues, the actual role code should be the one doing the type casting to the expected type, see e.g. ansible/ansible#13574 (comment)
Indeed, manually modifying the local checkout of the os_hardening role and modifying the entries to use the following does solve the problem:
I could provide a patch but I'd just like to get first a heads-up about the approach. Thanks!
OS / Environment
macOS 12.6
Ansible Version
Role Version
The text was updated successfully, but these errors were encountered: