ansible-lint
ansible-lint copied to clipboard
Rule 208 (Wrong/Missing file permission) ignores configured module_defaults
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
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.
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.
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.