ansible-lint icon indicating copy to clipboard operation
ansible-lint copied to clipboard

Rule 208 (Wrong/Missing file permission) ignores configured module_defaults

Open fleaz opened this issue 3 years ago • 2 comments

Summary

Hey everyone, I used module_defaults in my playbook to save me some writing by configuring defaults for owner,group and mode of the copy and template module. This works as expected, but ansible-lint still complains with rule 208 because my copy and template tasks (allegedly) don't have correct file permissions set.

Issue Type
  • Bug Report
Ansible and Ansible Lint details

ansible --version

ansible 2.9.12
  config file = /home/fleaz/codemonauts/ffni-monitoring/ansible.cfg
  configured module search path = ['/home/fleaz/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.8/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.8.5 (default, Jul 27 2020, 08:42:51) [GCC 10.1.0]

ansible-lint --version

ansible-lint 4.3.6.dev5+gcff352f

(also tested with 4.3.5 from pip)
  • ansible installation method: OS package
  • ansible-lint installation method: pip and git
OS / ENVIRONMENT

Arch Linux

STEPS TO REPRODUCE

Define owner,group and mode with module_defaults for e.g. the copy module and then use the copy module in your playbook.

test.yml:

---
- hosts: all
  module_defaults:
    copy:
      owner: root
      group: root
      mode: 0644
  tasks:
    - name: copy a file
      copy:
        src: files/foo
        dest: /tmp/foo

Desired Behaviour

Ansible-lint should interpret the module_defaults and see that the copy module has implicit values for owner,mode,group via the module_defaults

Actual Behaviour

Ansible-lint complains that the copy task has no configured file permissions.

# ansible-lint test.yml                       
[208] File permissions unset or incorrect
foo.yml:10
Task/Handler: copy a file

fleaz avatar Oct 06 '20 14:10 fleaz

Just wanted to gently nudge on this issue and check what the expected behavior (and potential solutions) here would be -- It seems like this bug (if it considered one) would be affecting all modules and not just the template module (since module_defaults don't seem to be parsed at all). I'm guessing this would be a non-trivial feature to implement.

I'd really appreciate any guidance y'all could provide here.

pratheekrebala avatar Jan 28 '22 22:01 pratheekrebala

That is a very tricky feature to implement and even when implemented there will be several uncovered cases, mainly because is close to impossible to know where the code is called from.

For now you should always define valid default values.

We would welcome a PR that sorts this issue within the boundaries of a single file but implementing this would require significant changes to task normalization routine.

ssbarnea avatar May 04 '22 13:05 ssbarnea

The args[module] rule has this same issue, I propose the documentation of lacking this support is moved from a rule to a dedicated documentation section such as "limitations" (where other limitations should be listed as well). The explanation "changing task location can also change task behavior" seems like a cop-out: of course moving a task changes the behavior - if that'd be an issue then module_defaults could never be used.

I get that it may be complex to implement if evaluating rules have no context like which block it runs in. Until someone steps up for some major changes (?) the best thing to do would be to document the limitations clearly.

Edit: If "changing task location can also change task behavior" is really a problem then what about block that has a when or delegate_to? It just seems quite far-fetched TBH.

bluikko avatar Dec 22 '22 12:12 bluikko