We are running the FreeIPA containers in GitHub Actions of https://github.com/freeipa/freeipa-container. With sssd 2.10.0-3.fc42 packages in Fedora rawhide the https://github.com/freeipa/freeipa-container/actions/runs/12461283683 run passed, with sssd 2.10.1-2.fc42 the https://github.com/freeipa/freeipa-container/actions/runs/12489404343 started to fail for rawhide, on all runtimes. It is also easy to reproduce the issue locally with tests/run-partial-tests.sh Dockerfile.fedora-rawhide In /var/log/sssd/ldap_child.log I then see (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed: Permission denied ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2024-12-25 16:41:58): [ldap_child[6484]] [sss_log_process_caps] (0x0100): Starting under ruid=285, euid=285, suid=285 : rgid=284, egid=284, sgid=284 * (2024-12-25 16:41:58): [ldap_child[6484]] [sss_log_process_caps] (0x0100): With following capabilities: (nothing) * (2024-12-25 16:41:58): [ldap_child[6484]] [main] (0x2000): context initialized * (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): total buffer size: 56 * (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): command: Select principal * (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): realm_str size: 12 * (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): got realm_str: EXAMPLE.TEST * (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): princ_str size: 16 * (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): got princ_str: ipa.example.test * (2024-12-25 16:41:58): [ldap_child[6484]] [unpack_buffer] (0x1000): keytab_name size: 0 * (2024-12-25 16:41:58): [ldap_child[6484]] [sss_set_cap_effective] (0x0400): cap_set_proc() failed: 1 ('Operation not permitted') * (2024-12-25 16:41:58): [ldap_child[6484]] [select_principal_from_keytab] (0x0200): trying to select the most appropriate principal from keytab * (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed: Permission denied ********************** BACKTRACE DUMP ENDS HERE ********************************* (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed: Permission denied * ... skipping repetitive backtrace ... (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed: Permission denied * ... skipping repetitive backtrace ... (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed: Permission denied * ... skipping repetitive backtrace ... (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed: Permission denied * ... skipping repetitive backtrace ... (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed: Permission denied * ... skipping repetitive backtrace ... (2024-12-25 16:41:58): [ldap_child[6484]] [find_principal_in_keytab] (0x0020): krb5_kt_start_seq_get failed: Permission denied * ... skipping repetitive backtrace ... (2024-12-25 16:41:58): [ldap_child[6484]] [select_principal_from_keytab] (0x0010): Failed to read keytab [FILE:/etc/krb5.keytab]: No suitable principal found in keytab I see capabilities and file permission related changes in https://github.com/SSSD/sssd/commits/master/ and in https://src.fedoraproject.org/rpms/sssd/c/80a939719c9fd4226e7eefc0d3d93c494501cbcd?branch=rawhide. I am able to workaround the issue by reverting the capabilities back to those I see in sssd 2.10.0-2.fc41, namely setcap cap_chown,cap_dac_read_search,cap_setgid,cap_setuid=ep /usr/libexec/sssd/krb5_child setcap cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep /usr/libexec/sssd/ldap_child and putting in /usr/lib/systemd/system/sssd.service.d/capabilities.conf with [Service] # In sssd-common-2.10.1-2.fc42.x86_64: # CapabilityBoundingSet= CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH # In sssd-common-2.10.0-2.fc41.x86_64: CapabilityBoundingSet= CAP_CHOWN CAP_DAC_OVERRIDE CAP_SETGID CAP_SETUID CAP_DAC_READ_SEARCH Things are not proken outside of containers. So it seems CAP_DAC_READ_SEARCH does not work (is not enough) in containerized setups. Reproducible: Always Steps to Reproduce: 1. git clone https://github.com/freeipa/freeipa-container 2. cd freeipa-container/ 3. # to get the state where (a planned) workaround is not present git checkout d062ba708896d4e0e97d28ac2681097d935cde02 4. # enable a test which does not use the external volume, to minimize impact of that containerization feature sed -i 's/^## # test: systemd-container-ipa-server-install.sh/# test: systemd-container-ipa-server-install.sh/' Dockerfile.fedora-rawhide 5. docker=podman tests/run-partial-tests.sh Dockerfile.fedora-rawhide Actual Results: ● sssd.service loaded failed failed System Security Services Daemon Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. Yeah, it's not a good error message. It tries to say that sssd.service is failed. Expected Results: No error. I understand Fedora does not primarily ship SSSD to work in containers, so this is mostly a headsup that recent changes in the packaging don't seem quite compatibly with current state of container runtimes.
I've also opened https://github.com/containers/podman/discussions/24904 to gather feedback from the podman folks.
I've verified that adding --cap-add=cap_dac_read_search to the $docker run also addresses the problem. So the issue seems to be that cap_dac_read_search is not among the default set of capabilities that containers get.
Hi, (In reply to Jan Pazdziora from comment #0) > > setcap cap_chown,cap_dac_override,cap_setgid,cap_setuid=ep > /usr/libexec/sssd/ldap_child 'cap_chown' is not needed. Replacement of 'cap_dac_read_search=p' with 'cap_dac_override=ep' does the trick for you, but (as you already figured out) the real cause is (In reply to Jan Pazdziora from comment #2) > I've verified that adding --cap-add=cap_dac_read_search to the $docker run > also addresses the problem. > > So the issue seems to be that cap_dac_read_search is not among the default > set of capabilities that containers get. In SSSD ci we just allowed everything required explicitly: https://github.com/SSSD/sssd-ci-containers/commit/211908d635758488211803530151aa43d6b04048