Is the removal of SSSD temporary until SELinux is fixed upstream?

[ccrpc-fjunge]

SSSD was removed in the 2026-03-31 release.

The commit appears to link this to a bug in the SELinux labeling of sssd-passkey: 8aa6bba

fix(packages): remove sssd cluster packages causing ostree update failures
Mirrors ublue-os/aurora PR 1811 and PR 1911. Removes libsss_autofs, sssd-ad,
and sssd-krb5 which pull in a dependency chain that causes silent ostree update
failures due to incorrect SELinux labeling of sssd-passkey artifacts.

The sssd-passkey issue appears to be tracked here in SELinux: fedora-selinux/selinux-policy#3081

For those whose organizations use Active Directory to authenticate users, would the recommended path forward be to stay pinned on the 2026-03-24 version until a fix is implemented and SSSD is added back in (if it would be added back in) or would it be to layer those packages?

[castrojo]

It's been my understanding that a bunch of this stuff hasn't been working in bootc, I think we've turned it on and off a few times already.

Happy to fix this, we'd love to support this but don't have lots of feedback. My AD managing days are over, I didn't even know people were actively using this! But yeah, I'm totally up for bringing it back!

[ccrpc-fjunge]

My coworkers (was two other people; currently one other person) and I have been using it successfully for over a year at this point. The last time it bricked was actually back in January 2025 (see also https://universal-blue.discourse.group/t/bluefin-enterprise-woes/6157 and SSSD/sssd#7784).

I can definitely keep an eye on fedora-selinux/selinux-policy#3081 and https://bugzilla.redhat.com/show_bug.cgi?id=2447274 and report back when / if that gets resolved.

[ccrpc-fjunge]

Digging into this a bit more, I have a follow up question.

The actual bug being referenced seems to be related to an SeLinux policy error with the sssd_passkey package, which the package freeipa-client that Aurora was using pulls in, that prevents the bootc upgrade command.

The freeipa-client package was removed from Bluefin back in September 2025 (61bdfbc).

None of the three packages, libsss_autofs, sssd-ad, nor sssd-krb5 seem to either require or recommend sssd_passkey (checked with dnf repoquery --recommends and dnf repoquery --requires).

In Aurora PR 1811 (ublue-os/aurora#1811) the fix was to remove the freeipa-client package. Aurora PR 1911 (ublue-os/aurora#1911) says it is a follow up to 1811 and also states its upstream bug is https://bugzilla.redhat.com/show_bug.cgi?id=2417703, which is also an IPA issue.

Aurora PR 1911 is the PR that removes the additional sssd packages. I may be missing something (I have attempted to thoroughly look through the issues but there is always a chance I misunderstood) but the removal of the other sssd packages appears to be a general cleanup step as Aurora does not have any non freeipa-client uses of sssd, rather than due to them causing a separate bug.

As Bluefin does not have / has not had the freeipa-client package for quite some time now, and the sssd packages have non freeipa-client uses (namely how my coworker and I are using it), and those three packages do not pull in sssd_passkey which is having the SELinux Polixy bug which is causing bootc upgrade to fail, would them remaining in Bluefin cause any issues?

I am unsure if there is a way for me to test this, as I mentioned my coworker and I have been using sssd to connect to the Windows Active Directory and Kerberos that our organization uses for over a year now without issue.

[ccrpc-fjunge]

@castrojo Would you have any additional insights on this?

[castrojo]

I am not sure, no access to an AD - at this point someone will have to go and figure it out and tell us what to ship.

[personalcyber]

Don't if this helps, but I needed ipa-client for my environment. The workaround in the build was to add a workaround in the build to put SELinux into permissive mode for the duration of the switch, then reboot:

sudo setenforce 0
sudo bootc switch ghcr.io/personalcyber/bluefin-freeipa:latest
# or: sudo bootc upgrade
sudo setenforce 1
systemctl reboot

setenforce 0 is transient — it only lasts until the next reboot. On first boot into the new image, the deployed image's own SELinux policy activates and the filesystem is automatically relabeled. This is safe because security is restored as soon as the new image boots.

https://github.com/personalcyber/bluefin-freeipa/#troubleshooting-selinux-permission-errors-during-switch-or-upgrade