We use 1password to store some of the secrets used in our playbooks. The CLI tool to retrieve has multiple methods for authorization/sessions, some set an environment variable and some are linked to the TTY. The recommended method (desktop app integration) uses the TTY, which doesn’t work in Ansible.
Expected behavior:
- Call the
opCLI tool to retrieve secrets, delegated to localhost - Get prompt by desktop app to approve this action
- Subsequent calls to the
opCLI caching this approval
Actual behavior:
- Call the
opCLI tool to retrieve secrets, delegated to localhost - Get prompt by desktop app to approve this action
- Keep getting prompts for every call
After some debugging I traced this back to each worker calling setsid after forking, thus making it impossible to cache authorizations. Confirmed to be the culprit by locally patching the call to setpgrp, which makes it behave like expected.
This seems to have been introduced in commit 8127abbc298cabf04aaa89a478fc5e5e3432a6fc, and already discussed in some issues on GitHub (primarily #85536 it seems). Staring a new sessions is claimed to be intentional, “mostly to avoid child processes from accessing the parent TTY directly and corrupting data sent back”. The workaround there ended up being to loosen restrictions of sudo, which isn’t possible with 1password due to security reasons.
Ansible already already detaches the TTY from stdin/stdout/stderr for new forks, so to mess with the TTY a sub process would have to go out of its way to grab the file descriptors from the session leader. For our use case this would be desired for 1password, and acceptable for other local processes.
A setting to “downgrade” the forks from separate sessions to separate process groups would be ideal. Alternatively, creating a PTY that’s shared across the workers should allow 1password to at least cache it within on Ansible run, though I’ve not done much testing/investigation yet on that.
If I missed and/or misunderstood something, please do let me know 