What were you trying to do that didn't work?

Supporting image mode work, we've been testing image mode builds using GitHub Actions which requires a nested "buildah bud in docker" build approach. The build succeeds, but the resulting image mode host has a raft of SELinux failures when run.

The build log shows the first policy picking up a previous fix for CoreOS related cross-device links:

 Running scriptlet: pcp-selinux-6.2.2-7.el9_5.x86_64 119/367     
libsemanage.semanage_rename: WARNING: rename(/etc/selinux/targeted/active, /etc/selinux/targeted/previous) failed: Invalid cross-device link, fall back to non-atomic semanage_copy_dir_flags()

But every following policy fails the rename operation:

 Running scriptlet: cockpit-ws-323.1-1.el9_5.x86_64 261/367        libsemanage.semanage_commit_sandbox: Error while renaming /etc/selinux/targeted/tmp to /etc/selinux/targeted/active. (Directory not empty).        libsemanage.semanage_commit_sandbox: Error while renaming /etc/selinux/targeted/previous back to /etc/selinux/targeted/active. (Directory not empty).     
/usr/sbin/semodule: Failed!

When installed, the resulting host throws a number of SELinux errors, in this case not allowing cockpit to function normally.

Building the image on a local machine or VM does not show the subsequent failures, and the host runs fine with all the expected SELinux policies active and correct. This appears to just affect this nested build case.

walters@redhat.com suggested this may be seeing a different error than the original fix from #COS-1238 which we can see firing at the first policy in the logs.

What is the impact of this issue to you?

Builds via Github Actions and potentially other CI/CD systems may have incorrect SELinux policies causing different kinds of failures.

Please provide the package NVR for which the bug is seen:

policycoreutils-python-utils-3.6-2.1.el9.noarch

python3-libsemanage-3.6-2.1.el9_5.x86_64

How reproducible is this bug?:

100% in GitHub actions where containerfiles have more than one custom policy, but overall seems to require a particular infrastructure config. Log files from a build of the smallest reproducer I can think of have been attached.

Containerfile.httpd

Steps to reproduce

1. Create containerfile with cockpit and cockpit-pcp installed
2. Build via GitHub Action workflow
3. Install image mode host as VM and attempt to log into cockpitlogs_36146457155.zip

Expected results

No SELinux alerts on running host, all services running.

Actual results

SELinux blocks cockpit operations due to label issues.