Sssd-maintainers April 2025

sssd-maintainers@lists.fedoraproject.org

1 participants
5 discussions

[Bug 2333179] New: ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/gpo_cache/* (code=exited, status=1/FAILURE)
by bugzilla＠redhat.com 03 Dec '25

03 Dec '25

https://bugzilla.redhat.com/show_bug.cgi?id=2333179 Bug ID: 2333179 Summary: ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/gpo_cache/* (code=exited, status=1/FAILURE) Product: Fedora Version: 41 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Keywords: Upgrades Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: gregory.lee.bartholomew(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora sssd.service fails to start when the /var/lib/sss/gpo_cache directory is empty. Reproducible: Always Steps to Reproduce: # This happened on two servers that I just updated. 0. have sssd configured as a ldap client 1. dnf update --releasever=41 && reboot Actual Results: [root@redacted gpo_cache]# systemctl status sssd.service × 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: failed (Result: exit-code) since Wed 2024-12-18 19:57:28 CST; 1min 56s ago Duration: 34.808s Invocation: b86216780f7849ec9a6c69a271a88fe9 Process: 672112 ExecStartPre=/bin/chown -f sssd:sssd /etc/sssd (code=exited, status=0/SUCCESS) Process: 672114 ExecStartPre=/bin/chown -f sssd:sssd /etc/sssd/sssd.conf (code=exited, status=0/SUCCESS) Process: 672116 ExecStartPre=/bin/chown -f -R sssd:sssd /etc/sssd/conf.d (code=exited, status=0/SUCCESS) Process: 672118 ExecStartPre=/bin/chown -f -R sssd:sssd /etc/sssd/pki (code=exited, status=0/SUCCESS) Process: 672120 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/db/*.ldb (code=exited, status=0/SUCCESS) Process: 672123 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/gpo_cache/* (code=exited, status=1/FAILURE) Process: 672125 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/log/sssd/*.log (code=exited, status=0/SUCCESS) Process: 672127 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=1/FAILURE) Main PID: 672127 (code=exited, status=1/FAILURE) IO: 0B read, 0B written Mem peak: 43.5M CPU: 505ms Dec 18 19:56:53 redacted.com sssd_pam[672133]: Starting up Dec 18 19:57:00 redacted.com sssd_be[672182]: Starting up Dec 18 19:57:03 redacted.com sssd_be[672262]: Starting up Dec 18 19:57:17 redacted.com sssd_be[672374]: Starting up Dec 18 19:57:28 redacted.com sssd[672127]: Exiting the SSSD. Could not restart criti…dap]. Dec 18 19:57:28 redacted.com sssd_ssh[672134]: Shutting down (status = 0) Dec 18 19:57:28 redacted.com sssd_pam[672133]: Shutting down (status = 0) Dec 18 19:57:28 redacted.com sssd_nss[672132]: Shutting down (status = 0) Dec 18 19:57:28 redacted.com systemd[1]: sssd.service: Main process exited, code=exi…ILURE Dec 18 19:57:28 redacted.com systemd[1]: sssd.service: Failed with result 'exit-code'. Expected Results: [root@redacted gpo_cache]# systemctl status sssd.service ● 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 2024-12-18 20:00:07 CST; 4s ago Invocation: 724c16248ba44bd681be6e4baeef858e Process: 673775 ExecStartPre=/bin/chown -f sssd:sssd /etc/sssd (code=exited, status=0/SUCCESS) Process: 673777 ExecStartPre=/bin/chown -f sssd:sssd /etc/sssd/sssd.conf (code=exited, status=0/SUCCESS) Process: 673779 ExecStartPre=/bin/chown -f -R sssd:sssd /etc/sssd/conf.d (code=exited, status=0/SUCCESS) Process: 673782 ExecStartPre=/bin/chown -f -R sssd:sssd /etc/sssd/pki (code=exited, status=0/SUCCESS) Process: 673784 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/db/*.ldb (code=exited, status=0/SUCCESS) Process: 673786 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/lib/sss/gpo_cache/* (code=exited, status=0/SUCCESS) Process: 673788 ExecStartPre=/bin/sh -c /bin/chown -f sssd:sssd /var/log/sssd/*.log (code=exited, status=0/SUCCESS) Main PID: 673790 (sssd) IO: 0B read, 0B written Tasks: 5 (limit: 153881) Memory: 42M (peak: 42.7M) CPU: 274ms CGroup: /system.slice/sssd.service ├─673790 /usr/sbin/sssd -i --logger=files ├─673799 /usr/libexec/sssd/sssd_be --domain ldap --logger=files ├─673800 /usr/libexec/sssd/sssd_nss --logger=files ├─673801 /usr/libexec/sssd/sssd_pam --logger=files └─673802 /usr/libexec/sssd/sssd_ssh --logger=files Dec 18 20:00:07 redacted.com sssd[673790]: Starting up Dec 18 20:00:07 redacted.com sssd_be[673799]: Starting up Dec 18 20:00:07 redacted.com sssd_nss[673800]: Starting up Dec 18 20:00:07 redacted.com sssd_ssh[673802]: Starting up Dec 18 20:00:07 redacted.com sssd_pam[673801]: Starting up I was able to work around the problem by running the following command: touch /var/lib/sss/gpo_cache/dummy -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2333179 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 26

[Bug 2351336] New: /etc/krb5.conf.d/enable_sssd_conf_dir is mistakenly in package sssd-krb5, not in sssd-krb5-common
by bugzilla＠redhat.com 02 Dec '25

02 Dec '25

https://bugzilla.redhat.com/show_bug.cgi?id=2351336 Bug ID: 2351336 Summary: /etc/krb5.conf.d/enable_sssd_conf_dir is mistakenly in package sssd-krb5, not in sssd-krb5-common Product: Fedora Version: 41 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: hey(a)runiq.de QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora I have used realmd to join a host to an Active Directory domain. Realmd uses sssd-ad for this, which pulls in sssd-krb5-common but _not_ sssd-krb5. Unfortunately, sssd-krb5-common does not install the snippet /etc/krb5.conf.d/enable_sssd_conf_dir. This results in SSH refusing gssapi-with-mic authentication. When I additionally install the sssd-krb5 package (which includes the snippet), or create the snippet manually, SSH logins use my SSSD config and GSSAPI authentication goes through. Reproducible: Always Steps to Reproduce: 1. Install realmd on a host 2. Join host to Active Directory domain 3. Enable SSH daemon 4. ssh -l user@realm -o preferredauthentications=gssapi-with-mic host Actual Results: Authentication is denied, no SSH session opened Expected Results: Authentication goes through, SSH session is opened -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2351336 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 7

[Bug 2325893] New: sssd gpo_child doesn't have sufficient rights to populate GPO policies
by bugzilla＠redhat.com 02 Dec '25

02 Dec '25

https://bugzilla.redhat.com/show_bug.cgi?id=2325893 Bug ID: 2325893 Summary: sssd gpo_child doesn't have sufficient rights to populate GPO policies Product: Fedora Version: 41 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Keywords: CommonBugs, Desktop Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: nekopilot(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora # 1. Issue After upgrade from F39 to F41 via UI path the login to the system with AD account is not possible. Local account works well. # 2. Workaround sssd service works under sssd user in Fedora 41. The folder with GPO policies has wrong rights with owner root: ls -lah /var/lib/sss/gpo_cache/example.com/Policies/ total 0 drwx------. 4 root root 98 Jan 10 2024 . drwx------. 3 sssd sssd 22 Jan 10 2024 .. drwx------. 3 root root 36 Nov 13 07:33 {31B2F332-016D-11D2-945F-00C04FBB84F9} drwx------. 3 root root 36 Nov 13 07:33 {7E50761D-1E4D-4D2B-BD86-E667EED3DF1E} It is possible to change the owner of the directories. After that the login with AD account works well. chown -R sssd:sssd /var/lib/sss/gpo_cache Reproducible: Always Steps to Reproduce: 1. Your F39 system must be joined to AD with sssd and you can login to the system with AD account. 2. Upgrade from F39 to F41. 3. Try to login with AD account. Actual Results: Login from Gnome UI is not possible with error: "Wrong user name or password". Expected Results: You can login to the system with AD account. Your F39 system must be joined to AD with sssd and you can login to the system with AD account. After upgrade you can't login from UI with AD account but: 1. kinit user.name(a)example.com - works well. 1. id user.name(a)example.com - works well. 1. realm list - looks good. In logs you can find error message: cat /var/log/sssd/gpo_child.log ``` [gpo_child[4066]] [prepare_gpo_cache] (0x0020): [RID#23] mkdir(/var/lib/sss/gpo_cache/example.com/Policies/{31B2F332-016D-11D2-945F-… failed: 13 ``` -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2325893 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2319608] New: python3-sssdconfig packs outdated .pyc files
by bugzilla＠redhat.com 20 Jun '25

20 Jun '25

https://bugzilla.redhat.com/show_bug.cgi?id=2319608 Bug ID: 2319608 Summary: python3-sssdconfig packs outdated .pyc files Product: Fedora Version: rawhide OS: Linux Status: NEW Component: sssd Keywords: Regression Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: jpazdziora(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, mzidek(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora The /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/*.cpython-313.pyc /usr/lib/files get regenerated when SSSDConfig module is used. Reproducible: Always Steps to Reproduce: 1. dnf install -y python3-sssdconfig 2. stat /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc 3. python3 -c 'import SSSDConfig' 4. stat /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc Actual Results: [root@0890eef375bc /]# stat /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc File: /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc Size: 57759 Blocks: 120 IO Block: 4096 regular file Device: 0,109 Inode: 1226072 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2024-10-15 00:00:00.000000000 +0000 Modify: 2024-10-15 00:00:00.000000000 +0000 Change: 2024-10-18 09:46:42.433097566 +0000 Birth: 2024-10-18 09:46:42.432097551 +0000 [root@0890eef375bc /]# python3 -c 'import SSSDConfig' [root@0890eef375bc /]# stat /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc File: /usr/lib/python3.13/site-packages/SSSDConfig/__pycache__/__init__.cpython-313.pyc Size: 59402 Blocks: 120 IO Block: 4096 regular file Device: 0,109 Inode: 1196042 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2024-10-18 09:47:14.646592272 +0000 Modify: 2024-10-18 09:47:14.646592272 +0000 Change: 2024-10-18 09:47:14.646592272 +0000 Birth: 2024-10-18 09:47:14.646592272 +0000 Expected Results: The Size and Modify time in the second stat run should match the output from the first one. First found by https://github.com/freeipa/freeipa-container/actions/runs/11397511703/job/3…. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2319608 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 9

[Bug 2361759] New: sssd version 2.10.2 forgets group membership information after an hour
by bugzilla＠redhat.com 24 Apr '25

24 Apr '25

https://bugzilla.redhat.com/show_bug.cgi?id=2361759 Bug ID: 2361759 Summary: sssd version 2.10.2 forgets group membership information after an hour Product: Fedora Version: 42 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: high Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: fedoraproject(a)ferree-clark.org QA Contact: extras-qa(a)fedoraproject.org CC: abokovoy(a)redhat.com, atikhono(a)redhat.com, lslebodn(a)redhat.com, pbrezina(a)redhat.com, sbose(a)redhat.com, ssorce(a)redhat.com, sssd-maintainers(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora After upgrading to sssd version 2.10.2, on hosts running both Fedora 41 and 42, sssd "forgets" group membership information after about an hour. After this occurs, the "id" command shows the user's password information and local (/etc/group) information but does not include groups that come from freeipa. Likewise, the getent group <freeipa groupname> command shows the group number and name, but does not include group members. Restarting sssd does not fix the problem, and neither does clearing the cache, even deleting the cache files. Forcing the sssd to switch ipa servers does cause group membership information to return, but again it disappears after an hour. I have confirmed that group membership information is correct when queried directly from freeipa when sssd does not display it. Reverting to sssd version 2.10.0 fixes the problem. This bug is causing havoc with applications that depend on particular group membership. Reproducible: Always Steps to Reproduce: 1.Start sssd for the first time (or force it to switch ipa servers) 2.Wait about an hour 3.Perform group query: getent group homeassistant (or any other freeipa group) Actual Results: homeassistant:*:637200008: Expected Results: homeassistant:*:637200008:user1,user2,user3 Additional Information: I have not been able to find errors in the logs that would explain this behavior. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2361759 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 7

2025

2024

2023

2022

2021

2020

Sssd-maintainers April 2025