Like #657, the problem is the --privileged in
# build the hardened image using a containerized builder,
podman.podman(
'container', 'run',
'--rm',
'--privileged',
'--security-opt', 'label=type:unconfined_t',
'--volume', f'{bootc_output_dir}:/output',
'--volume', '/var/lib/containers/storage:/var/lib/containers/storage',
'quay.io/centos-bootc/bootc-image-builder',
# arguments for the builder itself
'build',
'--type', 'qcow2',
'--local',
# 'localhost/' prefix tells the builder to just use local image storage
'localhost/contest-hardened',
)This effectively gives hard root of the host OS to anything inside the container, allowing it to mount devtmpfs, modify SELinux labels and do many very privileged operations when building the qcow2.
This also means that it can never work when running Contest inside a container - the nested podman is not a big deal, but --privileged expecting real OS init namespace level root access is a problem.
Newer bootc-image-builder versions (post-January-2026) can spin up a temporary VM via an --in-vm option instead, but would be rather wasteful and is still experimental.
Instead, we could re-use the CentOS Stream 10 temp VM idea from #657, possibly caching the downloaded image in /var/tmp across tests, and just run the podman container run ... --privileged ... quay.io/centos-bootc/bootc-image-builder ... inside that temp VM.
That would give it "real OS" access to the OS running inside the temp VM (additionally making the test more predictable / reproducible), without needing init namespace root on the OS that runs Contest, allowing the test itself to run in a container.
Like #657, the problem is the
--privilegedinThis effectively gives hard root of the host OS to anything inside the container, allowing it to mount
devtmpfs, modify SELinux labels and do many very privileged operations when building the qcow2.This also means that it can never work when running Contest inside a container - the nested podman is not a big deal, but
--privilegedexpecting real OS init namespace level root access is a problem.Newer
bootc-image-builderversions (post-January-2026) can spin up a temporary VM via an--in-vmoption instead, but would be rather wasteful and is still experimental.Instead, we could re-use the CentOS Stream 10 temp VM idea from #657, possibly caching the downloaded image in
/var/tmpacross tests, and just run thepodman container run ... --privileged ... quay.io/centos-bootc/bootc-image-builder ...inside that temp VM.That would give it "real OS" access to the OS running inside the temp VM (additionally making the test more predictable / reproducible), without needing init namespace root on the OS that runs Contest, allowing the test itself to run in a container.