Inconsistent become behavior between install and uninstall

[kkeane]

In the following playbook (running against a RHEL 9.4 host), the falcon_install role will work without specifying become: true, and error out when become: true is provided (the error is caused by sudo demanding a password. That's another oddity because my Ansible user should be able to do sudo without password). Apparently, the falcon_install role will elevate privileges internally.

The falcon_uninstall role behaves the reverse way. It will fail if become: true is omitted, but succeed if become: true is specified.

I do not know exactly how falcon_configure behaves.

Expected result: either both roles should require become: true, or neither should (the second would be preferable).

- name: Servers with Crowdstrike Falcon
  hosts:
    - crowdstrike_falcon
  roles:
  - role: crowdstrike.falcon.falcon_install
    # become: True will lead to sudo requesting a password
    vars:
      falcon_client_id:     "XXX"
      falcon_client_secret: "XXX"
      falcon_cloud:         "XXX"
  - role: crowdstrike.falcon.falcon_configure
    vars:
      falcon_client_id:     "XXX"
      falcon_client_secret: "XXX"

- name: Servers without Crowdstrike Falcon
  hosts:
    - all
    - '!crowdstrike_falcon'
  roles:
  - role: crowdstrike.falcon.falcon_uninstall
    become: true
    vars:
      falcon_client_id:     "XXX"
      falcon_client_secret: "XXX"
      falcon_cloud:         "XXX"
      falcon_remove_host:   true

[carlosmmatos]

@kkeane Thanks for opening this up!

The problem with become: true is due to the crowdstrike.falcon modules running locally on the Ansible control/master node. Since these are API calls, they don't require root permissions - only access to the python dependencies listed on the installation guide. So basically the concept of become: true in our case is handled already in each roles tasks/main.yml file since these would be the steps that actually require root privs to do something (ie, install/uninstall/run a priv command, etc).

I will look into the described issue with the uninstall role, as this should not require you to specify become: true either.

[carlosmmatos]

@kkeane was indeed a bug with uninstall role. Thanks for finding it!