SSSD binaries missing capabilities in Bazzite 41 vs. Kinoite 41

[rayrayrayraydog]

Describe the bug

Upon upgrading Bazzite to F41, I found that my layered install of SSSD was broken. I also found that the same SSSD setup would work when added to a new install of Kinoite 41.

In a test VM of Bazzite from the 41 ISO, I was able to recreate this issue. I think I've narrowed it down to a few binaries used by SSSD not having capabilities assigned as they do with the same package on Kinoite.

bazzite system:

root@bazzite:/usr/libexec/sssd# getcap *
selinux_child cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep

kinoite system:

root@kinotest:/usr/libexec/sssd# getcap *
krb5_child cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep
ldap_child cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep
selinux_child cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep
sssd_pam cap_dac_read_search=p

What did you expect to happen?

I would expect the binaries _krb5child, _ldapchild, and _sssdpam under /usr/libexec/sssd to have the proper capabilities so that SSSD services can function. I cannot directly modify them as they are under /usr. This was not an issue in bazzite on F39, wherein SSSD ran under the root account.

I realize that the bazzite team doesn't touch SSSD and doesn't ship it, but given that it works out of the box on Kinoite with the same version of the package I can't rule out something in bazzite's setup.

Output of rpm-ostree status

root@bazzite:/usr/libexec/sssd# rpm-ostree status State: idle Deployments: ● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable Digest: sha256:dd21242732e272339c1e5d9cee6441f95e819223e12d53cf1430a3db517d6bd6 Version: 41.20241029.1 (2024-10-29T15:39:27Z) LayeredPackages: adcli htop krb5-workstation libguestfs-tools libvirt libvirt-daemon-config-network libvirt-daemon-kvm oddjob oddjob-mkhomedir plasma-workspace-x11 pugixml qemu-kvm sssd terminator virt-install virt-manager virt-top virt-viewer

ostree-image-signed:docker://ghcr.io/ublue-os/bazzite:stable Digest: sha256:dd21242732e272339c1e5d9cee6441f95e819223e12d53cf1430a3db517d6bd6 Version: 41.20241029.1 (2024-10-29T15:39:27Z) LayeredPackages: adcli htop krb5-workstation libguestfs-tools libvirt libvirt-daemon-config-network libvirt-daemon-kvm oddjob

Hardware

This is a KVM virtual machine built with the latest bazzite-stable.iso for F41.

root@bazzite:/usr/libexec/sssd# cat /sys/devices/virtual/dmi/id/product_name Standard PC (Q35 + ICH9, 2009)

Extra information or context

No response

[antheas]

Is the sssd binary new? @KyleGospo can add a seuid in the Dockerfile for now as i dont feel like bumping rechunk

Oh we never checked for that directory

[rayrayrayraydog]

Is the sssd binary new? @KyleGospo can add a seuid in the Dockerfile for now as i dont feel like bumping rechunk

Oh we never checked for that directory

It was a non-issue until F41 where the service account sssd was added to run the services as non-root. It's mentioned here: https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/sysadmin/

Thank you for helping support an edge case like this.

[antheas]

https://github.com/hhd-dev/rechunk/releases/tag/v1.0.1 @KyleGospo

[rayrayrayraydog]

Noticed this morning that the SSSD package is installed by default in bazzite and Fedora in general. The file _selinuxchild that has capabilities comes from another package I had layered to get it working with MS AD.

[karypid]

So then, if I understand correctly upgrading from f40 to f41 has some script that changes file ownership permissions somewhere? Or is this part of the new RPM post-install scripts?

This is interesting. If the latter, I would expect everything in /usr to have the proper permissions, but how would this be addressed for /etc files in atomic distros? What does Fedora Silverblue do? Perhaps the problem is present there as well?

[antheas]

We are using a derived image from kinoite that gets rechunked in the end

Onenof the quirks of doing this is that we lose the xattrs of the original image for now. If we didn't rechunk the image we would lose the derived xattrs instead

In any case, what changed in f41 is that sssd is now part of kinoite, which caused it to lose its xattrs. So we had to add them back in

Rechunk 1.0.1 is merged in testing so next bazzite build will have them fixed

[karypid]

I updated Bluefin gts today and can no longer login via sssd:

AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 41min ago
Deployments:
  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:gts
                   Digest: sha256:c7d12e8d5e6bf444ffa3c0c740aaaa5bbc204360d0315b6389d96538fa8f4bb8
                  Version: 40.20241102.0 (2024-11-03T05:44:06Z)
                     Diff: 25 upgraded, 5 removed, 6 added
          LayeredPackages: touchegg

● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:gts
                   Digest: sha256:dfc42faacfffa0f990206db843e9a9cd84f58a99374b7f81123ca4aeaebead4c
                  Version: 40.20241029.0 (2024-10-29T18:30:00Z)
          LayeredPackages: touchegg
                   Pinned: yes

I have rolled back to the 40.20241029.0 build which still works fine. I am not sure if something has been merged (that should not have been) in 40-based images, or maybe they are also affected and need the same fix?

Furthermore, after facing the same issue on my second system, I instead upgraded to Bluefin latest (41-based) and that seems to work fine:

AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:latest
                   Digest: sha256:27d65e684ef5e4159e480ec4c531b137579d31707773cba9d13bf75dbbf47495
                  Version: 41.20241103.0 (2024-11-03T04:44:01Z)
          LayeredPackages: pwgen

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:gts
                   Digest: sha256:64fc3f87ad0249f9d6b3284c60168948e0c5a4e54cb54943b91d133abe5dfc5a
                  Version: 40.20241102.0 (2024-11-03T05:44:36Z)
          LayeredPackages: pwgen

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:stable
                   Digest: sha256:75fe45926ca23fe63414bc42b22f40e650decc1eae8d6d4b621e7d8e6b3721d0
                  Version: 40.20241027.0 (2024-10-27T05:46:52Z)
          LayeredPackages: pwgen
                   Pinned: yes

I can also confirm that ownership has changed:

❯ sudo ls -al /var/lib/sss/
total 0
drwxrwxr-x. 1 sssd sssd  100 May  2  2024 .
drwxr-xr-x. 1 root root 1042 Nov  3 17:20 ..
drwxrwx---. 1 sssd sssd  394 Nov  3 17:20 db
drwxrwx--x. 1 sssd sssd    0 Apr 30  2024 deskprofile
drwxrwx---. 1 sssd sssd    0 Apr 30  2024 gpo_cache
drwx------. 1 root root    0 Apr 30  2024 keytabs
drwxrwxr-x. 1 sssd sssd   48 Nov  3 17:20 mc
drwxrwxr-x. 1 sssd sssd   32 Nov  3 17:20 pipes
drwxrwxr-x. 1 sssd sssd  108 Nov  3 17:25 pubconf
drwxrwx---. 1 sssd sssd   22 Apr 30  2024 secrets

localuser in 🌐 myhost in ~ 
❯ ps -ef | grep sssd
sssd        1550       1  0 17:20 ?        00:00:00 /usr/sbin/sssd -i --logger=files
sssd        1561    1550  0 17:20 ?        00:00:00 /usr/libexec/sssd/sssd_be --domain ad.home.lan --logger=files
sssd        1563    1550  0 17:20 ?        00:00:00 /usr/libexec/sssd/sssd_nss --logger=files
sssd        1564    1550  0 17:20 ?        00:00:00 /usr/libexec/sssd/sssd_pam --logger=files
sssd        1565    1550  0 17:20 ?        00:00:00 /usr/libexec/sssd/sssd_pac --logger=files
sssd        2966       1  0 17:20 ?        00:00:00 /usr/libexec/sssd/sssd_kcm --logger=files
localus+   31124   28469  0 17:34 pts/1    00:00:00 grep --color=auto sssd

Not sure if any fix has been merged, but just reporting the data points here in case they are useful.

[antheas]

@castrojo update to rechunk 1.0.1 to fix this

[castrojo]

We bumped to 1.0.1 yesterday but that was after the stable builds went out, I'll push out new ones shortly.

[castrojo]

OK @karypid - images are updated, let me know!

[rayrayrayraydog]

@castrojo Do you mean a beta image? I'm not seeing anything yet.