UB
Universal Blue•4mo ago
Bloodfire

SSSD broken, unable to login since capabilities changes made to sssd-2.10.1

SSSD is currently broken in bazzite, meaning you can't login when using LDAP/FreeIPA/etc. Bazzite issue here: https://github.com/ublue-os/bazzite/issues/2030 This had a fix pushed through via rechunk here: https://github.com/hhd-dev/rechunk/pull/9 However, rechunk changes are not applying in the images built. You can see this here: https://github.com/ublue-os/bazzite/issues/2088 Right now this means anyone not using local login is stuck on 41.20241216.0 until the build-bot is fixed to appropriately apply the fix merged in the above PR. 
# Capabilities currently:
getcap /usr/libexec/sssd/*
/usr/libexec/sssd/krb5_child cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/ldap_child cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/selinux_child cap_setgid,cap_setuid=p
/usr/libexec/sssd/sssd_pam cap_dac_read_search=p

# Expected capabilities as per upstream changes:
/usr/libexec/sssd/krb5_child cap_dac_read_search,cap_setgid,cap_setuid=p
/usr/libexec/sssd/ldap_child cap_dac_read_search=p
/usr/libexec/sssd/selinux_child cap_setgid,cap_setuid=p 
/usr/libexec/sssd/sssd_pam cap_dac_read_search=p
# Capabilities currently:
getcap /usr/libexec/sssd/*
/usr/libexec/sssd/krb5_child cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/ldap_child cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep
/usr/libexec/sssd/selinux_child cap_setgid,cap_setuid=p
/usr/libexec/sssd/sssd_pam cap_dac_read_search=p

# Expected capabilities as per upstream changes:
/usr/libexec/sssd/krb5_child cap_dac_read_search,cap_setgid,cap_setuid=p
/usr/libexec/sssd/ldap_child cap_dac_read_search=p
/usr/libexec/sssd/selinux_child cap_setgid,cap_setuid=p 
/usr/libexec/sssd/sssd_pam cap_dac_read_search=p
Hopefully the build bot can be fixed soon as this is a breaking change that prevents upgrades.
GitHub
SSSD binaries capabilities have changed · Issue #2030 · ublue-os/ba...
Describe the bug Followup to #1818 Since 41.20241229 sssd.service fails to start. Dec 29 23:20:23 <redacted> systemd[1]: Starting sssd.service - System Security Services Daemon... Dec 29 23:2...
GitHub
fix: add case statement for setting sssd capabilities based on Fedo...
To fix ublue-os/bazzite#2030 without breaking previous SSSD versions capabilities. I&#39;m not sure if there&#39;s a better place to put functions, but that could certainly be changed. I cr...
GitHub
Image build not including rechunk changes · Issue #2088 · ublue-os/...
Describe the bug It looks like rechunk is not applying the appropriate changes to the bazzite image, resulting in retained sssd failures. hhd-dev/rechunk#9 Which should fix: #2030 What did you expe...
9 Replies
Bloodfire
BloodfireOP•4mo ago
Hoping posting it in the discord will increase visibility, referencing appropriate bazzite github issues pages to make it easier 🙂
wolfyreload
wolfyreload•4mo ago
@antheas sorry to ping you. You might want to have a look at this.
antheas
antheas•4mo ago
kyle said he'd update it did he @Kyle Gospo update it
Bloodfire
BloodfireOP•4mo ago
Hello again @antheas thanks so much for your work last week on that PR 🙂 as of 41.20250106.2 it was still bork bork by the way. Is the build bot not upstream change aware? Feels like a trigger is not in place if that's the issue.
Kyle Gospo
Kyle Gospo•4mo ago
Yeah testing should have the latest Stable will for the next build as well, it's there
antheas
antheas•4mo ago
try testing
Bloodfire
BloodfireOP•3mo ago
ok I'll rebase to testing after work unless new stable is released prior haha did not work but i see a new merge went into rechunk that address version detection fixes 
OSTREE_VERSION='41.20250115.0'
BUILD_ID="Testing (F41.20250115, #9665cbc)"
BOOTLOADER_NAME="Bazzite Testing (F41.20250115, #9665cbc)"
OSTREE_VERSION='41.20250115.0'
BUILD_ID="Testing (F41.20250115, #9665cbc)"
BOOTLOADER_NAME="Bazzite Testing (F41.20250115, #9665cbc)"
systemctl status sssd
● sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf, 50-keep-warm.conf
     Active: active (running) since Wed 2025-01-15 13:20:11 EST; 10min ago
systemctl status sssd
● sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf, 50-keep-warm.conf
     Active: active (running) since Wed 2025-01-15 13:20:11 EST; 10min ago
Looks like latest testing works 🙂 can't wait for latest stable 🙂 any idea when the stable release should come with this fix? been two weesk since the last stable and I'm quite excited.
antheas
antheas•3mo ago
kyle is feeling under the weather, he will try to fix some build errors and build today testing is fine, we havent been doing much unstable stuff
MCPottercraft
MCPottercraft•3mo ago
I'm also having issues with SSSD and it's driving me nuts. The error I'm getting is permission denied on startup of the sssd service for /etc/sssd/sssd.conf I've tried stable-41.20250120, stable-41.20250127, testing-41.20250127.1 The capabilities of /usr/libexec/sssd/* are the new expected values The permissions of /etc/sssd/sssd.conf are "-rw-r-----. 1 root sssd" which seems correct. The selinux attributes on the file are "unconfined_u:object_r:sssd_conf_t:s0", I've set it to "system_u" with no luck. I have another system on fedora 41 but not bazzite that seems to be identical for sssd and it works fine Any help would be much appreciated thanks Figured it out, /etc/sssd needs to be group executable sudo chmod g+x /etc/sssd

Did you find this page helpful?