Role tasks mess up the entire system's permissions

It looks like under certain circumstances, this role seems to be wreaking havoc where it is provisioned. It changes the permissions of the entire root folder (!?).

Example output:

TASK [cloudalchemy.node-exporter : Install dependencies] *********************************************************************************************************************

TASK [cloudalchemy.node-exporter : Create the node_exporter group] ***********************************************************************************************************
changed: [the_vm_ip]

TASK [cloudalchemy.node-exporter : Create the node_exporter user] ************************************************************************************************************
fatal: [the_vm_ip]: FAILED! => {"changed": false, "msg": "[Errno 1] Operation not permitted: '/proc/sys'"}

After this failure, I SSH’d into the system and found this…

system-username@vm-hostname:~$ ls -la /
total 88
drwxr-xr-x  23 node-exp users  4096 Oct 16 12:43 .
drwxr-xr-x  23 node-exp users  4096 Oct 16 12:43 ..
drwxr-xr-x   2 node-exp users  4096 Oct 10 19:31 bin
drwxr-xr-x   3 node-exp users  4096 Oct 10 19:32 boot
drwxr-xr-x  16 node-exp users  3580 Oct 16 12:43 dev
drwxr-xr-x 103 node-exp users  4096 Oct 16 13:01 etc
drwxr-xr-x  18 node-exp users  4096 Oct 16 12:59 home
lrwxrwxrwx   1 root     root     31 Oct 10 19:32 initrd.img -> boot/initrd.img-4.15.0-1046-gcp
lrwxrwxrwx   1 root     root     31 Oct 10 19:32 initrd.img.old -> boot/initrd.img-4.15.0-1046-gcp
drwxr-xr-x  20 node-exp users  4096 Oct 16 12:51 lib
drwxr-xr-x   2 node-exp users  4096 Oct 10 19:29 lib64
drwx------   2 node-exp users 16384 Oct 10 19:31 lost+found
drwxr-xr-x   2 node-exp users  4096 Oct 10 19:29 media
drwxr-xr-x   2 node-exp users  4096 Oct 10 19:29 mnt
drwxr-xr-x   2 node-exp users  4096 Oct 10 19:29 opt
dr-xr-xr-x 717 node-exp users     0 Oct 16 12:43 proc
drwx------   4 node-exp users  4096 Oct 16 12:51 root
drwxr-xr-x  23 node-exp users   940 Oct 16 13:02 run
drwxr-xr-x   2 node-exp users  4096 Oct 10 19:31 sbin
drwxr-xr-x   2 node-exp users  4096 Oct 16 12:43 snap
drwxr-xr-x   2 node-exp users  4096 Oct 10 19:29 srv
dr-xr-xr-x  13 node-exp users     0 Oct 16 12:48 sys
drwxrwxrwt   8 node-exp users  4096 Oct 16 13:01 tmp
drwxr-xr-x  10 node-exp users  4096 Oct 10 19:29 usr
drwxr-xr-x  14 node-exp users  4096 Oct 16 12:51 var
lrwxrwxrwx   1 root     root     28 Oct 10 19:32 vmlinuz -> boot/vmlinuz-4.15.0-1046-gcp
lrwxrwxrwx   1 root     root     28 Oct 10 19:32 vmlinuz.old -> boot/vmlinuz-4.15.0-1046-gcp

The above is a VM running in GCP. I have another VM running in GCP where I have run the same version of the role against it and this did not happen.

This is the playbook where this is happening:

# Playbook where the issue happens
---
- hosts: "{{ hosts_group }}"
  gather_facts: true
  become: true
  roles:
    - role: lifeofguenter.oracle-java
      become: yes
    - role: jobscore.beats
      become: yes
    - role: torian.logstash
       become: yes
    - role: cloudalchemy.node-exporter

And this is the playbook where this does not happen:

# Playbook where problem does not occur
---
- hosts: "{{ hosts_group }}"
  gather_facts: yes
  roles:
    - role: jobscore.beats
      become: yes
    - role: torian.logstash
      become: yes
    - role: cloudalchemy.node-exporter

And this is the requirements.yml file used in both projects:

---
- src: https://github.com/jobscore/ansible-role-beats/archive/v0.1.1.tar.gz
  name: jobscore.beats
- src: https://github.com/torian/ansible-role-logstash/archive/1.2.0.tar.gz
  name: torian.logstash
- src: https://github.com/lifeofguenter/ansible-role-oracle-java/archive/1.0.2.tar.gz
  name: lifeofguenter.oracle-java
- src: https://github.com/cloudalchemy/ansible-node-exporter/archive/0.15.0.tar.gz
  name: cloudalchemy.node-exporter

The only visible difference is the become: true defined in the playbook where this happens. But still, why would the role change the permissions of the entire system? 🤔

[walterdolce]

Yes at some point we found a bug in a version of Ansible but a version of devel (the commit in question) did not have that bug and so we pinned it to that version. I will give it a try with the latest version of Ansible to see what happens first.

Excellent MTTR (Mean Time To Reaction in this case), BTW 👏

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.