ansible.windows.win_owner module fails to run recursively if ansible_user does not have access to the child items

[smarshie]

SUMMARY

In an attempt to clear and repopulate access control lists for a folder and its child items (folders and files), I cleared all access permissions manually from items and then attempted to set the owner recursively using this module. The action fails with the message that access is denied to the folder. When you do the same thing in the Windows UI, the option to set ownership recursively is provided and works flawlessly in this same scenario.

ISSUE TYPE

• Bug Report

COMPONENT NAME

win_owner

ANSIBLE VERSION

ansible [core 2.16.3]
  config file = /home/smarshie/git/devops/group-it/environments/ansible_common/ansible.cfg
  configured module search path = ['/home/smarshie/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/smarshie/.venv/ansible/lib/python3.11/site-packages/ansible
  ansible collection location = /var/cache/devops
  executable location = /home/smarshie/.venv/ansible/bin/ansible
  python version = 3.11.7 (main, May 16 2024, 00:00:00) [GCC 11.4.1 20231218 (Red Hat 11.4.1-3)] (/home/smarshie/.venv/ansible/bin/python)
  jinja version = 3.1.3
  libyaml = True

COLLECTION VERSION

Collection      Version
--------------- -------
ansible.windows 2.2.0

CONFIGURATION

ANSIBLE_FORCE_COLOR(/home/smarshie/git/devops/group-it/environments/ansible_common/ansible.cfg) = True
COLLECTIONS_PATHS(/home/smarshie/git/devops/group-it/environments/ansible_common/ansible.cfg) = ['/var/cache/devops']
CONFIG_FILE() = /home/smarshie/git/devops/group-it/environments/ansible_common/ansible.cfg
DEFAULT_FORKS(/home/smarshie/git/devops/group-it/environments/ansible_common/ansible.cfg) = 30
DEFAULT_GATHERING(/home/smarshie/git/devops/group-it/environments/ansible_common/ansible.cfg) = smart
DEFAULT_STRATEGY(/home/smarshie/git/devops/group-it/environments/ansible_common/ansible.cfg) = free
HOST_KEY_CHECKING(/home/smarshie/git/devops/group-it/environments/ansible_common/ansible.cfg) = False

OS / ENVIRONMENT

STEPS TO REPRODUCE

1. Remove all acl entries and inheritance for a folder and its child items
2. Run a playbook (as a user with admin rights) containing the task shown below

Error message is:

fatal: [<SERVER_NAME>]: FAILED! => {"changed": false, "msg": "an error occurred when attempting to change owner on C:\Certbot for : Access to the path 'C:\Certbot\accounts' is denied."}

A task in an included role

- name: Ensure certbot folder ownership is set
  become: true
  when: ansible_facts['os_family'] == 'Windows'   
  ansible.windows.win_owner:
    path: C:\Certbot
    user: "{{ ansible_user }}"
    recurse: true

EXPECTED RESULTS

The ownership should be set as the current ansible user on the folder and its child items. (This then allows adding inheritable permissions to the same)

ACTUAL RESULTS

TASK [acdlabs.certbot.certbot : Ensure certbot folder ownership is set] ******************************************************************
fatal: [kat06_webserver]: FAILED! => {"changed": false, "msg": "an error occurred when attempting to change owner on C:\\Certbot for smarsh: Access to the path 'C:\\Certbot\\accounts' is denied."}

[jborean93]

While the module should probably enable the privilege if present I believe the problem is stemming from using become: true on the task. When you don't use become all the account's privileges will be enabled which includes SeRestorePrivilege, SeBackupPrivilege, and SeTakeOwnershipPrivilege needed to set the owner when you don't have rights to do so normally. When you use become those privileges will still be present, they are just not enabled by default. You can see the difference by running and seeing the values for privileges

- win_whoami:

- win_whoami:
  become: true

I'll work on fixing up the module so it'll enable those privileges explicitly to work in these scenarios but hopefully that workaround will get you going for now.

[jborean93]

I've opened #634 which does a minor rewrite of the module but will also enable those 3 privileges explicitly to work in a become scenario. I've also added some tests to verify that this actually fixes the problem.

Thanks for reporting this bug and sharing this info!