Bug 2417703
| Summary: | Cannot login with IPA account when freeipa-client is bundled in bootc image | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | William Oprandi <william.oprandi> | ||||||
| Component: | ostree | Assignee: | Colin Walters <walters> | ||||||
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 43 | CC: | abokovoy, amurdaca, atikhono, coreos-sig, dustymabe, ftrivino, ipa-maint, jmarrero, jonathan, lslebodn, mhjacks, miabbott, pbrezina, rcritten, rob, robert-fedora, sbose, ssorce, sssd-maintainers, travier, twoerner, walters | ||||||
| Target Milestone: | --- | Keywords: | Desktop | ||||||
| Target Release: | --- | Flags: | atikhono:
needinfo?
(walters) fedora-admin-xmlrpc: mirror+ |
||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | --- | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | Type: | --- | |||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
William Oprandi
2025-11-28 14:49:56 UTC
Please compare with my setup using KDE. This works with freeipa and Kinoite. Maybe also a selinux issue? https://gitlab.com/eu-os/eu-os.gitlab.io/-/snippets/4906744#L106 selinux_provider = none in /etc/sssd/sssd.conf seems to "fix" the issue. This is not needed when freeipa-client is installed with rpm-ostree ! Thanks a lot as a workaround exists now ! William, can you please provide the debug log of SSSD? Nov 28 14:16:45 qemu-standardpcq35ich92009-notspecified.fr.otera.lan gdm-password][3816]: pam_sss(gdm-password:account): Access denied for user william.oprandi: 4 (Erreur syst�me) We need to understand whether SSSD selinux provider is affected by a variant of https://github.com/ostreedev/ostree-rs-ext/issues/510. Created attachment 2116979 [details]
SSSD logs
The SSSD logs folder from restart to login failure
Ok, looks like SELinux SSSD child is failing indeed: * (2025-12-01 14:13:11): [be[fr.otera.lan]] [child_handler_setup] (0x2000): [RID#14] Setting up signal handler up for pid [4036] * (2025-12-01 14:13:11): [be[fr.otera.lan]] [child_handler_setup] (0x2000): [RID#14] Signal handler set up for pid [4036] .. (2025-12-01 14:13:11): [be[fr.otera.lan]] [child_sig_handler] (0x0020): [RID#14] child [4036] failed with status [1]. Unfortunately, the selinux_child.log is empty, so we don't know why this happened. My suspicion is that it is indeed an issue with SELinux library not being able to load its own database. Maybe you need I change the SSSD debug level ? Yes, please use 'debug_level = 9'. Created attachment 2117046 [details]
SSSD debug level 9
SSSD logs with sss_debuglevel 9 ran
Thanks. I'm moving this bug to SSSD so that they can analyze what's happening. Hi, could you please show output of ``` ls -lahZ /usr/libexec/sssd/ getcap /usr/libexec/sssd/* ``` ? $ ls -lahZ /usr/libexec/sssd/ total 2,5M drwxr-xr-x. 2 root root system_u:object_r:bin_t:s0 442 1 janv. 1970 . drwxr-xr-x. 53 root root system_u:object_r:bin_t:s0 8,0K 1 janv. 1970 .. -rwxr-x---. 1 root sssd system_u:object_r:bin_t:s0 137K 1 janv. 1970 krb5_child -rwxr-x---. 1 root sssd system_u:object_r:bin_t:s0 48K 1 janv. 1970 ldap_child -rwxr-xr-x. 1 root root system_u:object_r:ipa_otpd_exec_t:s0 60K 1 janv. 1970 oidc_child -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 72K 1 janv. 1970 p11_child -rwxr-xr-x. 1 root root system_u:object_r:ipa_otpd_exec_t:s0 56K 1 janv. 1970 passkey_child -rwxr-x---. 1 root root system_u:object_r:sssd_selinux_manager_exec_t:s0 36K 1 janv. 1970 selinux_child -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 73 1 janv. 1970 sss_analyze -rwxr-xr-x. 1 root root system_u:object_r:sssd_exec_t:s0 179K 1 janv. 1970 sssd_autofs -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 248K 1 janv. 1970 sssd_be -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 16K 1 janv. 1970 sssd_check_socket_activated_responders -rwxr-xr-x. 1 root root system_u:object_r:sssd_exec_t:s0 276K 1 janv. 1970 sssd_ifp -rwxr-xr-x. 1 root root system_u:object_r:sssd_exec_t:s0 211K 1 janv. 1970 sssd_kcm -rwxr-xr-x. 1 root root system_u:object_r:sssd_exec_t:s0 253K 1 janv. 1970 sssd_nss -rwxr-xr-x. 1 root root system_u:object_r:sssd_exec_t:s0 183K 1 janv. 1970 sssd_pac -rwxr-x---. 1 root sssd system_u:object_r:sssd_exec_t:s0 280K 1 janv. 1970 sssd_pam -rwxr-xr-x. 1 root root system_u:object_r:sssd_exec_t:s0 187K 1 janv. 1970 sssd_ssh -rwxr-xr-x. 1 root root system_u:object_r:sssd_exec_t:s0 187K 1 janv. 1970 sssd_sudo -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 12K 1 janv. 1970 sss_signal $ getcap /usr/libexec/sssd/* /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 The reason is: ``` -rwxr-x---. 1 root root system_u:object_r:sssd_selinux_manager_exec_t:s0 36K 1 janv. 1970 selinux_child ``` -- 'sssd_be' run under 'sssd' user can't execute `selinux_child`. It should be ':sssd' owned, as other privileged helpers (`krb5_child`, `ldap_child`, `sssd_pam`) spec-file installs it properly - as 'root:sssd': https://src.fedoraproject.org/rpms/sssd/blob/rawhide/f/sssd.spec#_801 I guess the problem is that you add it later: ``` RUN dnf install -y freeipa-client ``` but not sure yet what exactly is broken so that it ends up with a wrong ownership. So yes, this is the same issue as it was in https://github.com/ostreedev/ostree-rs-ext/issues/654 which was supposed to be fixed with https://github.com/ostreedev/ostree-rs-ext/pull/679. (In reply to Alexander Bokovoy from comment #13) > So yes, this is the same issue as it was in > https://github.com/ostreedev/ostree-rs-ext/issues/654 which was supposed to > be fixed with https://github.com/ostreedev/ostree-rs-ext/pull/679. Actually this looks different. ostree-rs-ext/issues/654 was about lost file capabilities. In this case it's wrong ownership. Colin, could you please take a look at this? (In reply to Alexey Tikhonov from comment #15) > Colin, could you please take a look at this? Changing component for better visibility. Please feel free to re-assign bug with explanation if this is SSSD bug. |