Fix SELinux detection in driver scripts

[Ashutosh0x]

This PR replaces the outdated filesystem check [ -e /sys/fs/selinux ] with a more robust call to selinuxenabled across all driver scripts.

Resolves NVIDIA/gpu-operator#1489

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[rajathagasthya]

/ok-to-test d07feae

[rahulait]

Thanks @Ashutosh0x. We removed some dirs which were not maintained by us. Please rebase the PR from latest main so that someone from the team can review the PR

@Shivkumar13 please take a look once updated.

[rajathagasthya]

@Ashutosh0x Are you able to update your PR as per @rahulait's suggestion?

[Ashutosh0x]

Hi @rahulait @rajathagasthya @Shivkumar13,

I have successfully rebased the branch onto the latest main and resolved all conflicts (removed the outdated/unsupported directories as requested). The branch is now clean and fully mergeable. Please take a look!

[rajathagasthya]

selinuxenabled is not installed by default in any of the base images. It requires libselinux-utils. So this check will always return false even if SELinux is enabled.

[Ashutosh0x]

@rajathagasthya Good catch, thanks for pointing that out! You're right — selinuxenabled requires libselinux-utils which isn't installed in any of the base images, so the check would always return false.

I've updated the approach: instead of using selinuxenabled, I've reverted to the original [ -e /sys/fs/selinux ] filesystem check but made the chcon calls non-fatal by appending || true. This way:

• SELinux enabled + chcon works → security context is set correctly ✅
• SELinux disabled but /sys/fs/selinux mounted → chcon fails gracefully, script continues ✅
• SELinux fully disabled → chcon is skipped entirely ✅

This avoids adding any new package dependencies while still preventing the script abort reported in #1489.

[rajathagasthya]

I think this is reasonable. selinuxenabled doesn't really help as it also checks for /etc/selinux/config file, which isn't present inside the container. But I'd like another set of eyes on this. cc @tariq1890 @rahulait

@Ashutosh0x How are you planning to test this?

[Ashutosh0x]

Hi @rajathagasthya @rahulait @Shivkumar13,

I have refactored the approach to resolve both the dependency concern and the risk of swallowing legitimate errors.

Instead of using selinuxenabled (which requires additional packages) or appending || true to the chcon commands (which risk ignoring genuine context failures when SELinux is active and enforcing), the scripts now check if the selinuxfs pseudo-filesystem is active and mounted:

if grep -qsw "selinuxfs" /proc/mounts && [ -f /sys/fs/selinux/enforce ]; then
    # Run chcon strictly here
fi

Here is the test matrix I've used to validate this change:

1. Scenario 1: SELinux Enforcing (e.g., RHEL/Fedora host)
   • Result: The script successfully detects selinuxfs in /proc/mounts and the enforce file. chcon runs strictly, applying security labels correctly.
2. Scenario 2: SELinux Permissive
   • Result: The /sys/fs/selinux/enforce file exists containing 0. The check evaluates to true, and chcon successfully labels files to ensure security contexts remain valid if the host transitions back to Enforcing.
3. Scenario 3: SELinux Disabled with leftover directories (The bug reported in #1489)
   • Result: Even if /sys/fs/selinux exists as a stub, selinuxfs is not present in /proc/mounts and /sys/fs/selinux/enforce does not exist. The check evaluates to false. chcon is cleanly skipped without any script aborts.
4. Scenario 4: No SELinux Support (e.g., standard Ubuntu/Debian environment)
   • Result: The check evaluates to false, skipping chcon and ensuring the script completes without error.

Please let me know if this looks good to merge!

[rahulait]

This change looks good to me. @tariq1890 do you have any concerns with this?

[tariq1890]

My understanding is that OpenShift clusters have SELinux enabled by default, so the DTK entrypoint changes don't really address the issue. If we want to change the DTK entrypoint, we can explore that in a different PR.

@Ashutosh0x How are you planning to test this?

I have the same question.