`reset-selinux-labels` fails with `Invalid argument` for sysexts without a custom SELinux policy module

[C-L-Istre]

It appears that since commit ca6aa02 (sysext.just: Install packages in SELinux stage as needed), building the libvirtd and libvirtd-desktop sysexts fails during the reset-selinux-labels step with:

setfiles: Could not set context for ./usr/bin/swtpm: Invalid argument
error: Recipe `reset-selinux-labels` failed with exit code 255

This affects both the FCOS and Fedora Atomic Desktop base images, confirming the issue is not specific to any one base image but affects any base image that does not ship the full Fedora SELinux policy.

For reference, simpler sysexts like python3 build successfully without any workaround, confirming the regression is specific to sysexts that include packages whose file contexts are absent from the base image policy.

Root cause

Commit ca6aa02 introduced an optimization that only installs packages inside the podman container during the SELinux labeling step when ./rootfs/usr/share/selinux/packages exists. The commit message states:

"We only need to install the packages from the sysext in the container if there are additional SELinux modules"

However, it seems this does not hold for sysexts that include packages whose file contexts exist in the full Fedora policy but are absent from the base image policy. Since neither libvirtd nor libvirtd-desktop ship a custom SELinux policy module, that directory is absent, so the container runs setfiles using only the bare base image policy.

The base image policy does not include file contexts for all packages in these sysexts — in particular swtpm, qemu-kvm, and related packages. When setfiles encounters a file with no matching context in the policy, it returns EINVAL.

Before ca6aa02, packages were always installed in the container before running setfiles, so the full Fedora policy was available and all files could be labeled correctly.

Steps to reproduce

1. Clone the repo on a host with SELinux enforcing
2. cd libvirtd (or cd libvirtd-desktop)
3. just build quay.io/fedora/fedora-coreos:stable x86_64 (or just build quay.io/fedora-ostree-desktops/base-atomic:42 x86_64)
4. Observe setfiles: Could not set context for ./usr/bin/swtpm: Invalid argument

Workaround

Override reset-selinux-labels in the local justfile to run setfiles directly on the host (requires root and a host with SELinux enforcing + full Fedora policy installed). Confirmed working for both libvirtd and libvirtd-desktop:

reset-selinux-labels target arch=arch:
    #!/bin/bash
    set -euo pipefail
    if [[ -n "{{debug}}" ]]; then
      set -x
    fi
    echo "🏷 Resetting SELinux labels"
    cd rootfs
    setfiles -r . /etc/selinux/targeted/contexts/files/file_contexts .
    chcon --user=system_u --recursive .

Expected behavior

Sysexts that do not ship a custom SELinux policy module but include packages whose file contexts are not in the base image policy should still be labeled correctly.

Environment

• Host OS: Fedora Server 43 (SELinux enforcing, targeted policy)
• Affected sysexts: libvirtd, libvirtd-desktop
• Target images affected:
  • quay.io/fedora/fedora-coreos:stable (libvirtd)
  • quay.io/fedora-ostree-desktops/base-atomic:42/43/44 (libvirtd-desktop)
• Likely affected: any sysext including packages not in the base image policy (e.g. swtpm, qemu-kvm) without a custom SELinux policy module

[travier]

Are you building from a toolbox as described in https://github.com/fedora-sysexts/fedora#building ? I don't remember if I was hitting that one too before I added the swtpm module to my policy.

This is worked-around in the CI here as the host (Ubuntu) does not run with SELinux enabled.

This is related to #35

[travier]

And this is likely not a regression from ca6aa02 as this will keep installing the packages as before for sysexts with SELinux modules.

[C-L-Istre]

Are you building from a toolbox as described in https://github.com/fedora-sysexts/fedora#building ? I don't remember if I was hitting that one too before I added the swtpm module to my policy.

This is worked-around in the CI here as the host (Ubuntu) does not run with SELinux enabled.

This is related to #35

I started in a toolbox on Kinoite 43 but was getting the same errors, I thought it was my build environment so I first created a new toolbox but ultimately ended up on Server 43 by time I applied the workaround.

I realize now that I had only built libvirtd-desktop in the toolbox I had used a few months ago to test #192 (never got around to trying libvirtd on FCOS #192 (comment)) but since this error was occurring regardless of which version I built last night I'm not sure it's relevant.

[C-L-Istre]

And this is likely not a regression from ca6aa02 as this will keep installing the packages as before for sysexts with SELinux modules.

You're probably right, sorry for the assumption, I was getting frustrated since this worked fine last time I had tried it so I ended up using claude to help troubleshoot. It suggested that ca6aa02 may have been the issue but I was suspicious since it had worked for me since that was introduced. As this was mostly over my head I decided to include it anyway in case it did end up having some relevance I didn't understand.

I'm going to pivot back to testing libvirtd-desktop for now since I'm limited on time and that was a much more straightforward process.

If there is anything you would like me to test I'll get to it as soon as I can but my current focus is getting @jbtrystram's suggestion #192 (comment) implemented.

[C-L-Istre]

While working on building an older version of PR #192 as a sanity check for an unrelated issue, I had an opportunity to test building the libvirtd* sysexts again in a new toolbox (as described in https://github.com/fedora-sysexts/fedora#building), but ran into the same error:

setfiles: Could not set context for ./usr/bin/swtpm: Invalid argument
error: Recipe `reset-selinux-labels` failed with exit code 255

For reference, this F43 toolbox on Kinoite 43 was able to build python3 successfully, same as the F43 Server environment. As expected, the workaround from above also failed in the toolbox, since /etc/selinux/targeted/contexts/files/file_contexts is not present inside the container (I believe this should only work on workstation/server with the full SELinux policy installed).

[travier]

You have two options:

• Build in a VM without SELinux or nested containers that have SELinux disabled or GitHub CI here in your fork as the runners don't have SELinux enabled
• Load the swtpm SELinux module on your host as you'll need it for swtpm to work with this sysext anyway.

[C-L-Istre]

Thanks, I have a working environment currently, I just wanted to document as much as I could since I didn't experience this when following the build instructions previously.

I'm happy to close this if it's already covered elsewhere, aside from being available to run more targeted tests I don't think I'll be of much help here anyway.

[travier]

It's a real problem but I haven't found a good way to fix it so far.