Support Ansible prepare step in image mode

[thrix]

Summary

• Add image mode (bootc) support for the ansible prepare plugin
• When running on a bootc guest, starts a container, runs ansible-playbook with containers.podman.podman connection plugin, commits the result, switches via bootc switch, and reboots
• Includes integration test following the tests/prepare/bootc/ pattern

Details

On image mode guests, /usr is read-only and system changes must be baked into the container image. The existing shell and install prepare plugins handle this via Containerfile directives, but the ansible plugin had no image mode support.

The implementation:

1. Flushes any pending containerfile directives from prior shell/install phases
2. Ensures ansible-playbook is available on the guest (installs ansible-core if needed)
3. Gets the current bootc image and ensures it's in podman storage
4. Starts a container from the image
5. Runs each playbook with ansible-playbook -c containers.podman.podman
6. Commits the container to a new image
7. Switches via bootc switch --transport containers-storage and reboots

Test plan

• Run existing prepare tests for regressions
• Run new tests/prepare/bootc-ansible/ test with an image mode guest
• Verify log output shows: container start, ansible-playbook with podman connection, commit, switch, reboot

Closes #4624

[gemini-code-assist]

Code Review

This pull request adds support for the Ansible prepare step in image mode (bootc), including a new integration test. However, a high-severity Path Traversal vulnerability and several instances of potential Command Injection were identified due to improper handling of user-supplied paths and command arguments, which could allow an attacker to read arbitrary files or execute unintended commands. It is recommended to use existing path sanitization helpers and switch from shell-based command execution to structured command objects.

[gemini-code-assist]

A high-severity Path Traversal vulnerability exists in the _resolve_playbook_for_guest method. It resolves local playbook paths by concatenating the plan's anchor path with a user-supplied path without proper validation, potentially allowing an attacker to read arbitrary files. The method fails to use the unrooted() helper or verify that the resulting path is within the anchor path. Additionally, consider refactoring the duplicated playbook resolution logic to improve maintainability.

Suggested change

	if lowercased.startswith('file://'):
	rel_path = Path(raw_playbook[7:])
	else:
	rel_path = Path(raw_playbook)
	local_path = self.step.plan.anchor_path / rel_path
	if lowercased.startswith('file://'):
	rel_path = Path(raw_playbook[7:])
	else:
	rel_path = Path(raw_playbook)
	local_path = self.step.plan.anchor_path / rel_path.unrooted()
	if not local_path.is_relative_to(self.step.plan.anchor_path):
	raise PrepareError(f"Playbook path '{raw_playbook}' is outside the plan directory.")

[gemini-code-assist]

The podman run command is constructed using an f-string and executed via ShellScript. Variables such as guest.run_workdir and current_image are included without proper shell quoting. While paths internally generated and controlled by the application, like guest.run_workdir, do not strictly require quoting for security against command injection, lack of quoting can still cause the command to fail if paths contain spaces. For current_image, if it's user-provided, this poses a command injection risk. Using the Command class is preferred as it handles argument quoting safely for all variables and improves robustness.

            # Start a container from the current bootc image
            logger.info('ansible', f'starting container {container_name}', 'green')
            podman_run_cmd = Command('podman', 'run', '-d')
            if guest.facts.sudo_prefix:
                podman_run_cmd = Command(guest.facts.sudo_prefix) + podman_run_cmd
            podman_run_cmd += Command('--name', container_name)
            podman_run_cmd += Command('-v', f'{guest.run_workdir}:{guest.run_workdir}:Z')
            podman_run_cmd += Command(current_image, 'sleep', 'infinity')
            guest.execute(podman_run_cmd)

References

1. Paths that are internally generated and controlled by the application do not need to be quoted in shell commands, as they are not considered user-provided input.

[gemini-code-assist]

The ansible-playbook command is constructed using an f-string and executed via ShellScript. Variables such as container_name, guest_playbook, and self.data.extra_args are included without proper shell quoting. While paths internally generated and controlled by the application, like container_name, do not strictly require quoting for security against command injection, lack of quoting can still cause the command to fail if paths contain spaces. For guest_playbook and especially self.data.extra_args (which is user-provided), this poses a significant command injection risk. Structured Command objects should be used instead of raw shell strings to handle argument quoting safely.

                    # Build the ansible-playbook command to run on the guest
                    ansible_cmd = Command('ansible-playbook')
                    if guest.facts.sudo_prefix:
                        ansible_cmd = Command(guest.facts.sudo_prefix) + ansible_cmd
                    ansible_cmd += Command('-c', 'containers.podman.podman', '-i', f'{container_name},', guest_playbook)

                    if self.data.extra_args:
                        import shlex
                        ansible_cmd += Command(*shlex.split(self.data.extra_args))

                    return guest.execute(ansible_cmd)

References

1. Paths that are internally generated and controlled by the application do not need to be quoted in shell commands, as they are not considered user-provided input.

[LecrisUT]

I do not like this approach. Please elaborate why you went with this and what other alternatives have you considered.

[LecrisUT]

Why is ansible required on the guest?

[thrix]

@LecrisUT this should happen on the guest to:

1. mitigate having an external container registry in place to share the images (or find some other crazy way how to get the base image from the guest and push it to the guest). The base container image is available only on the guest

2. Be similar to a regular container rebuild, less suprises, easier to explain how it works

[LecrisUT]

mitigate having an external container registry

The local container registry of the bootc runtime should be usable right?

Be similar to a regular container rebuild, less suprises

I disagree with this creating less surprises. E.g. if the package being tested is anything inside the ansible dependency stack, and this fails at the prepare step, how would one debug this? Having a minimal dependency footprint would be the best for the "less surprises"

---

Before anything, I would like a better breakdown of any other alternative approaches. From what I understand of bootc it is supposed to be possible to do local builds from the current state, don't know if bootc image copy-to-storage, but there seem to be many ways of interacting with bootc and would like to have a more thorough breakdown of it

[thrix]

The local container registry of the bootc runtime should be usable right?

it has nothing to do with bootc runtime, it is the guest local registry on the machine

I disagree with this creating less surprises. E.g. if the package being tested is anything inside the ansible dependency stack, and this fails at the prepare step, how would one debug this? Having a minimal dependency footprint would be the best for the "less surprises"

Not sure I follow, the failed preparation should be visible from the tmt logs?

Before anything, I would like a better breakdown of any other alternative approaches. From what I understand of bootc it is supposed to be possible to do local builds from the current state,

Local to what? guest or host?

don't know if bootc image copy-to-storage, but there seem to be many ways of interacting with bootc and would like to have a more thorough breakdown of it

I am not aware of any alternative approaches that would not require what I wrote

[LecrisUT]

Why the indirect bash

[LecrisUT]

👎 to this approach. It uses both a containers connection and it also runs on the guest!?

[thrix]

It was decided we will not support Ansible for now, only fix the playbooks for feature plugins to be image-mode friendly.

[thrix]

As discussed, closing this for now, we will go with #4625 by adjusting the playbooks to not use tasks which will not work in image mode (e.g. dnf)