Risks of becoming an unprivileged user
Ansible modules are executed on the remote machine by first substituting the
parameters into the module file, then copying the file to the remote machine,
and finally executing it there.
Everything is fine if the module file is executed without usingbecome,
when thebecome_useris root, or when the connection to the remote machine
is made as root. In these cases, Ansible creates the module file with
permissions that only allow reading by the user and root, or only allow reading
by the unprivileged user being switched to.
However, when both the connection user and thebecome_userare unprivileged,
the module file is written as the user that Ansible connects as (theremote_user), but the file needs to be readable by the user Ansible is set
tobecome. The details of how Ansible solves this can vary based on the platform.
However, on POSIX systems, Ansible solves this problem in the following way:
First, ifsetfaclis installed and available in the remotePATH,
and the temporary directory on the remote host is mounted with POSIX.1e
filesystem ACL support, Ansible will use POSIX ACLs to share the module file
with the second unprivileged user.
Next, if POSIX ACLs arenotavailable orsetfaclcould not be
run, Ansible will attempt to change ownership of the module file usingchownfor systems that support doing so as an unprivileged user.
New in Ansible 2.11, at this point, Ansible will trychmod +awhich
is a macOS-specific way of setting ACLs on files.