Use the security context of the playbook when checking out roles
When the executor checks out and runs content, the security context
(trusted or untrusted) comes in to play in two ways: whether
speculative merging should be used when checking out the content
and the level of access to ansible.
This is straightforward for playbooks: when running an untrusted
playbook, use the speculatively merged repo and the untrusted
ansible environment. When running a trusted playbook, only use
the branch tip of the playbook's repo, and the trusted ansible
environment.
When we consider roles, we also need to consider whether to use
the speculatively merged role repo, or the branch tip. The current
code uses the security context of the role repo to decide which to
do (untrusted role repo uses the speculatively merged repo,
trusted role repo uses branch tip). However this presents a problem.
Consider a job defined in a trusted repo which uses a role defined
in an untrusted repo. The playbook will be run in the trusted
execution context, but the role it depends on will come from the
speculatively-merged role repo. This means a user could propose a
change which Depends-On a change to the role repo and cause mischief.
The author of the job in the trusted repo should be able to rely on
the fact that when that job runs, both the playbook and the roles
used by that playbook only contain code that is actually in the
respective repositories. Likewise, should a job in an untrusted
repo inherit from that job, when its playbook runs, it should be
able to use a speculative change to the role repo.
In short, when we are running a trusted playbook, we should use the
branch tip of all role repos used by that playbook. And when we run
an untrusted playbook, we should use any speculatively merged changes
to those roles.
Since we can run both kinds of playbooks in a single job, this change
prepares roles in both manners, if necessary. If any playbook run by
the job is untrusted, we will prepare the speculatively-merged repo
as a role. If any playbook is trusted (or the role does not appear in
the dependency chain for the change), we prepare the branch tip of the
role repo. When we run the playbooks, we use the appropriate version
of each role based on the security context of the playbook.
Change-Id: I06dd3851a8f805dba9afe1b4a0eaa1b2fdd4efa2
3 files changed