ansible-core PR #87242 (ansible-vault EPERM fix) — review feedback addressed, awaiting re-review

Project Discussions
,
1

Hi folks,

I’d appreciate a second look at ansible-vault: tolerate EPERM when restoring ownership on edit/rekey by lawendy1 · Pull Request #87242 · ansible/ansible · GitHub — a small bugfix for ansible-vault edit and ansible-vault rekey crashing with PermissionError when the file’s previous group ownership cannot be restored. It’s the long-standing issue #11544, and it is easy to hit on macOS, where files created in /tmp inherit the directory’s wheel group through BSD group inheritance.

Where it stands:

  • @s-hertel kindly reviewed in July and asked for the unit tests to be replaced with integration tests. That was done the same week, in test/integration/targets/ansible-vault/runme.sh — the test drops CAP_CHOWN via setpriv --bounding-set=-chown so the EPERM path is actually reachable in CI, which otherwise runs as root and can never receive EPERM from chown. It covers both the edit and the rekey path.
  • CI is green, and the branch is mergeable with no conflicts.
  • There has been no activity since then, and the stale changes_requested review still blocks the PR.

If any core maintainer has a moment to re-review — or to tell me what else is needed — I’d be grateful. Happy to rebase or adjust anything.

The fix itself mirrors what AnsibleModule.preserved_copy() and atomic_move() already do in module_utils/basic.py: ignore errno.EPERM from the ownership-restore chown, and let every other error propagate.

Thanks!