Ticket was cloned from Red Hat Bugzilla: Bug 1583360

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

The SSSD selinux management routines were only checking if SELinux is managed on the system. If it is managed, the code tries to proceed and set the login context, otherwise an error is returned which SSSD handles gracefully.

But this is not enough, in some cases SELinux might be disabled, but managed and in these cases SSSD was returning strange errors, which might have prevented login with selinux provider in effect.

We got this hint form the RH SELinux maintainer:

libsemanage is for managing SELinux infrastructure. generally if there's /etc/selinux/config where libsemanage can read SELINUXTYPE and SELinux module store - /etc/selinux/<SELINUXTYPE>/active (or /var/lib/selinux/<SELINUXTYPE>/active) - is available, libsemanage can manage it even when SELinux is disabled.

I'm not sure if selinux_child doesn any is_selinux_enabled() checks but it could help to avoid such situations.