SSSD binaries missing capabilities in Bazzite 41 vs. Kinoite 41 #1818
Comments
|
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. |
|
Noticed this morning that the SSSD package is installed by default in bazzite and Fedora in general. The file selinux_child that has capabilities comes from another package I had layered to get it working with MS AD. |
|
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? |
|
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 |
|
I updated Bluefin gts today and can no longer login via sssd: 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: I can also confirm that ownership has changed: Not sure if any fix has been merged, but just reporting the data points here in case they are useful. |
|
@castrojo update to rechunk 1.0.1 to fix this |
|
We bumped to 1.0.1 yesterday but that was after the stable builds went out, I'll push out new ones shortly. |
|
OK @karypid - images are updated, let me know! |
|
@castrojo Do you mean a beta image? I'm not seeing anything yet. |
|
So, I think the problem is that the capabilities are only needed for 41-based images where the software runs as user At least this is the only difference I can find between the 3 images below, of which only the pinned works: In all 3 everything is owned and runs as root so that is common: But the 40.20241102.0 (gts) and 40.20241103.0 (stable-daily) have the new capabilities which I think are interfering (these are probably only needed for 41-based images): The older pinned 40.20241029.0 (gts) which is the only one that works, has no capabilities: As I reported yesterday, latest works fine, and has the capabilities, but is also 41-based and runs/owns the files as sssd.... |
That's odd. I'm on latest 41 but I don't see the capabilities there. Do you mean in Bluefin? |
Ah yes: as shown in my I am not clean on how much bazzite/bluefin share in the underlying infrastructure. Happy to file a separate bug report if this is not a ublue-os core issue. |
|
@rayrayrayraydog Hello from Bluefix-41. Just double-confirmed that latest is working fine: When running on Bluefin 41 (latest) everything is owned by sssd except keytabs (not sure if that is an issue, but it definitely doesn't prevent me from logging in): Everything runs as sssd: And the capabilities are present: Here is rpm-ostree status with 41.20241104.0 (latest) on bluefin-dx-nvidia channel: So it seems to me that Bluefin has the opposite problem:
|
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:
kinoite system:
What did you expect to happen?
I would expect the binaries krb5_child, ldap_child, and sssd_pam 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 statusroot@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
The text was updated successfully, but these errors were encountered: