bootc-operator CI breaking because of crio.sock missing

[jlebon]

See e.g. https://github.com/jlebon/bootc-operator/actions/runs/25672424696/job/75387684949

[preflight] Some fatal errors occurred:
Error: CRI]: could not connect to the container runtime: failed to create new CRI runtime service: validate
service connection: validate CRI v1 runtime API for endpoint "unix:///var/run/crio/crio.sock": rpc error: code
= Unavailable desc = connection error: desc = "transport: Error while dialing: dial unix /var/run/crio/
crio.sock: connect: no such file or directory"

[jlebon]

Throwing my agent against this gives:

---

CRI-O fails to start with:

/usr/bin/crio: error while loading shared libraries: cannot make segment writable
  for relocation: Permission denied

Root cause

Kernel 7.0 has a regression where SELinux mprotect() access checks on overlayfs (used by composefs/bootc) evaluate the backing file's security context instead of the overlay file's context. On composefs, the backing files are in the ostree object store and have a different (or no) security label.

This causes SELinux domain transitions to fail for binaries on the composefs rootfs. CRI-O, which should transition to container_runtime_t (which allows execmem), instead runs as kernel_t (which does not). CRI-O needs execmem because it is linked with -Wl,-z,notext (text relocations from the libgpgme CGO binding).

Verified by copying /usr/bin/crio to /var/tmp (ext4, not composefs) — it starts fine with SELinux enforcing.

Upstream fix

The fix is a 3-commit series by Paul Moore, landed in v7.1-rc1:

1. 880bd496ec72 — fs: prepare for adding LSM blob to backing_file
2. 6af36aeb147a — lsm: add backing_file LSM hooks
3. 82544d36b172 — selinux: fix overlayfs mmap() and mprotect() access checks

All tagged Cc: stable@vger.kernel.org but not yet backported to v7.0.x or the Fedora 43 kernel.

Fix

Pin the node image kernel to 6.19.14-200.fc43 until the upstream fix is backported. See commit 752ae5a.

This should be reverted once a Fedora 43 kernel with the fix is available.

---

I didn't deeply double-check it, but it looks plausible. Doing a second pass verification to confirm that just pinning to v6.19 indeed works.

[jlebon]

OK yup, can confirm 6.19 works. Let's pin for now: #53

But let's leave this open until we unpin.

[jlebon]

Took this to https://bugzilla.redhat.com/show_bug.cgi?id=2477939.

[buckaroogeek]

As an FYI on F44 cloud vm:

[vagrant@localhost crio]$ ls -laZ /var/run/crio/
total 4
drwxr-xr-x.  5 root root system_u:object_r:container_var_run_t:s0  140 May 15 18:10 .
drwxr-xr-x. 46 root root system_u:object_r:var_run_t:s0           1160 May 15 18:10 ..
srw-rw----.  1 root root system_u:object_r:container_var_run_t:s0    0 May 15 18:10 crio.sock
drwxr-x---.  2 root root system_u:object_r:container_var_run_t:s0   40 May 15 18:10 exec-pid-dir
drwxr-xr-x.  2 root root system_u:object_r:container_var_run_t:s0   40 May 15 18:10 exits
drwx------.  2 root root system_u:object_r:container_var_run_t:s0   40 May 15 18:10 seccomp
-rw-r--r--.  1 root root system_u:object_r:container_var_run_t:s0   16 May 15 18:10 version

[vagrant@localhost crio]$ ls -laZ /usr/bin/crio
-rwxr-xr-x. 1 root root system_u:object_r:container_runtime_exec_t:s0 75403848 Apr  2 00:00 /usr/bin/crio