Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

os_auth_retries variable causes a comparison type error on pam tasks #593

Closed
dlouzan opened this issue Oct 25, 2022 · 3 comments · Fixed by #594
Closed

os_auth_retries variable causes a comparison type error on pam tasks #593

dlouzan opened this issue Oct 25, 2022 · 3 comments · Fixed by #594
Labels

Comments

@dlouzan
Copy link
Contributor

dlouzan commented Oct 25, 2022

Describe the bug

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.

Example case:

- name: "Run dev-sec os-hardening"
  ansible.builtin.include_role:
    name: devsec.hardening.os_hardening
  vars:
    os_auth_retries: "{{ some_dict.os_auth_retries }}"
some_dict:
  os_auth_retries: 10

this produces:

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!

OS / Environment

macOS 12.6

Ansible Version

ansible [core 2.12.2]
  config file = None
  configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/user/.local/lib/python3.10/site-packages/ansible
  ansible collection location = /home/user/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/user/.local/bin/ansible
  python version = 3.10.2 (main, Feb 21 2022, 16:34:42) [Clang 13.0.0 (clang-1300.0.29.30)]
  jinja version = 3.0.3
  libyaml = True

Role Version

8.1.0
@schurzi schurzi added the bug label Oct 25, 2022
@schurzi
Copy link
Contributor

schurzi commented Oct 25, 2022

nice catch. We would be happy to accept a PR for this. :)

You can create a PR anytime, we only require to Sign-off your commits and to pass our CI tests.

@dlouzan
Copy link
Contributor Author

dlouzan commented Oct 26, 2022

@schurzi I will provide a patch this week, thanks again for the awesome project, we at Siemens are big fans 😁

@dlouzan
Copy link
Contributor Author

dlouzan commented Oct 27, 2022

Actually this also affects redhat pam files, I just had not experienced it yet because the way I was disabling some settings.

@dlouzan 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
@schurzi schurzi closed this as completed Oct 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants