checkpoint-restore / criu

Checkpoint/Restore tool
criu.org
Other
2.76k stars 559 forks source link

"Cirrus CI / Vagrant Fedora Rawhide based test" fails with error "setenforce: SELinux is disabled" #2406

Closed Snorch closed 1 month ago

Snorch commented 1 month ago

Description

Steps to reproduce the issue: Reproduces in CI https://github.com/checkpoint-restore/criu/pull/2380#pullrequestreview-2065281120 https://github.com/checkpoint-restore/criu/pull/2380/checks?check_run_id=25148861695 while executing scripts/ci/run-ci-tests.sh

Describe the results you received:

+ setenforce Permissive
setenforce: SELinux is disabled

Describe the results you expected:

No error.

adrianreber commented 1 month ago

This is unusual for Fedora to have SELinux disabled. We could extend our script to correctly handle disabled SELinux. There is a test earlier which checks if SELinux is mounted which is usually a sign of a disabled SELinux system. Probably a bug in Fedora rawhide.

adrianreber commented 1 month ago

Ah, okay. The rawhide tests runs in a container. Containers always have SELinux disabled from the inside. Somehow /sys/fs/selinux is now mounted. We used the existence of that directory if SELinux is available. This seems to be no longer true.

Something like this could help

diff --git a/scripts/ci/run-ci-tests.sh b/scripts/ci/run-ci-tests.sh
index c50dc4174..524adbac2 100755
--- a/scripts/ci/run-ci-tests.sh
+++ b/scripts/ci/run-ci-tests.sh
@@ -306,14 +306,18 @@ if [ "$skip" == 0 ]; then
        if [ -d /sys/fs/selinux ] && command -v getenforce &>/dev/null; then
                # Note: selinux in Enforcing mode prevents us from calling clone3() or writing to ns_last_pid on restore; hence set to Permissive for the test and then set back.
                selinuxmode=$(getenforce)
-               setenforce Permissive
+               if [ "$selinuxmode" != "Disabled" ]; then
+                       setenforce Permissive
+               fi
        fi
        # Run it as non-root in a user namespace. Since CAP_CHECKPOINT_RESTORE behaves differently in non-user namespaces (e.g. no access to map_files) this tests that we can dump and restore
        # under those conditions. Note that the "... && true" part is necessary; we need at least one statement after the tests so that bash can reap zombies in the user namespace,
        # otherwise it will exec the last statement and get replaced and nobody will be left to reap our zombies.
        sudo --user=#65534 --group=#65534 unshare -Ucfpm --mount-proc -- bash -c "./test/zdtm.py run -t zdtm/static/maps00 -f h --rootless && true"
        if [ -d /sys/fs/selinux ] && command -v getenforce &>/dev/null; then
-               setenforce "$selinuxmode"
+               if [ "$selinuxmode" != "Disabled" ]; then
+                       setenforce "$selinuxmode"
+               fi
        fi
        setcap -r criu/criu
 else