Sssd-maintainers February 2025

sssd-maintainers@lists.fedoraproject.org

1 participants
4 discussions

[Bug 2343602] New: TGT not renewd by KCM reliably
by bugzilla＠redhat.com 07 Feb '25

07 Feb '25

https://bugzilla.redhat.com/show_bug.cgi?id=2343602 Bug ID: 2343602 Summary: TGT not renewd by KCM reliably Product: Fedora Version: 41 Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: bojan(a)rexursive.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 Description of problem: TGT renewal is configured in /etc/sssd/sssd.conf (some settings redacted), but not working consistently: [kcm] tgt_renewal = true tgt_renewal_inherit = default and: [domain/default] id_provider = ldap ldap_id_use_start_tls = False auth_provider = krb5 chpass_provider = krb5 cache_credentials = true krb5_store_password_if_offline = true krb5_renewable_lifetime = 7d krb5_renew_interval = 5m krb5_use_fast = demand Version-Release number of selected component (if applicable): sssd-2.10.2-1.fc41.x86_64 (but also 2.10.1 and probably other versions) How reproducible: Sometimes. At times, sssd will renew the TGT. Steps to Reproduce: 1. Get krb5 TGT by logging in through pam_sss. 2. Suspend laptop, resume, rinse, repeat. Use U2F authentication to unlock Gnome lock screen (i.e. not password to refresh TGT). 3. Wait for the point where TGT does not get renewed, despite meeting conditions. Actual results (sanitised): $ klist Ticket cache: KCM:6000 Default principal: user(a)DOMAIN.COM Valid starting Expires Service principal 03/02/25 13:35:47 04/02/25 11:00:43 host/server.domain.com(a)DOMAIN.COM renew until 09/02/25 16:55:56 03/02/25 11:01:04 04/02/25 11:00:43 imap/mail.domain.com(a)DOMAIN.COM renew until 09/02/25 16:55:56 03/02/25 11:00:43 04/02/25 11:00:43 krbtgt/DOMAIN.COM(a)DOMAIN.COM renew until 09/02/25 16:55:56 03/02/25 11:27:00 04/02/25 11:00:43 nfs/server.domain.com(a)DOMAIN.COM renew until 09/02/25 16:55:56 03/02/25 15:54:15 04/02/25 11:00:43 smtp/mail.domain.com(a)DOMAIN.COM renew until 09/02/25 16:55:56 In the example above, a TGT issued for a day, which expires at 11:00 on this day, should be renewed, because as of this writing, it is 07:12, which means over half of the life of TGT already expired. And yet, it will not be, despite the laptop being on for over 5 minutes, which is the renewal lifetime. Whether the settings are explicitly configured or inherited does not seem to make a difference. Expected results: TGT should be renewed, as configured. Additional info: -- 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=2343602 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 5

[Bug 2336049] New: sssd still writes to old log files after rotation due to incorrect PID file location
by bugzilla＠redhat.com 31 Jan '25

31 Jan '25

https://bugzilla.redhat.com/show_bug.cgi?id=2336049 Bug ID: 2336049 Summary: sssd still writes to old log files after rotation due to incorrect PID file location Product: Fedora Version: 41 OS: Linux Status: NEW Component: sssd Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: orion(a)nwra.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 logs are not being rotated properly. This is due to: postrotate /bin/kill -HUP `cat /var/run/sssd.pid 2>/dev/null` 2> /dev/null || true /bin/pkill -HUP sssd_kcm 2> /dev/null || true endscript # cat /var/run/sssd.pid cat: /var/run/sssd.pid: No such file or directory # find /run -name sssd.pid /run/sssd/sssd.pid sssd-2.10.1-1.fc41.x86_64 Reproducible: Always -- 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=2336049 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 5

[Bug 2335130] New: rpm -Vaq complains about wrong owner
by bugzilla＠redhat.com 31 Jan '25

31 Jan '25

https://bugzilla.redhat.com/show_bug.cgi?id=2335130 Bug ID: 2335130 Summary: rpm -Vaq complains about wrong owner Product: Fedora Version: rawhide Hardware: x86_64 OS: Linux Status: NEW Component: sssd Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: pampelmuse(a)gmx.at 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 $ rpm -Vaq sssd-common .....U... /etc/sssd .....U... /etc/sssd/conf.d .....U... /etc/sssd/pki Reproducible: Always Steps to Reproduce: 1. fresh rawhide installation 2. rpm -Vaq sssd-common .....U... /etc/sssd .....U... /etc/sssd/conf.d .....U... /etc/sssd/pki Actual Results: wrong user Expected Results: no output Maybe in spec file line 850 should be: %attr(750,root,%{sssd_user}) %dir %{_sysconfdir}/sssd %attr(750,root,%{sssd_user}) %dir %{_sysconfdir}/sssd/conf.d %attr(750,root,%{sssd_user}) %dir %{_sysconfdir}/sssd/pki -- 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=2335130 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 7

[Bug 2334868] New: updating an existing system to sssd-2.10.1 causes sssd to fail with permissions issues
by bugzilla＠redhat.com 31 Jan '25

31 Jan '25

https://bugzilla.redhat.com/show_bug.cgi?id=2334868 Bug ID: 2334868 Summary: updating an existing system to sssd-2.10.1 causes sssd to fail with permissions issues Product: Fedora Version: 41 OS: Linux Status: NEW Component: sssd Keywords: Upgrades Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: roth(a)ursus.net 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 [this is on a ostree system (Fedora 41 Kinoite)] From what I can tell, the sssd permissions changed recently from root:sssd to sssd:sssd, and there are subtle differences in the way the config directories and config files are owned that cause the most recent update to fail. The previous version (2.10.0) had /etc/sssd at mode 0700, owned by root:sssd. Now that the service runs as sssd:sssd it is not able to access previous configs in /etc/sssd and the daemon fails with a permissions error. There are a couple of contributing factors to this update failure: 1. the three-way merge for /etc files done by ostree does not preserve file permissions, and does not update directory permissions. When /usr/etc/sssd changed from 0700 to 0750, this was not reflected in /etc/sssd. 2. the ExecStartPre= statements in sssd.service are a bit optimistic. The chown and chmod commands don't work with the current service settings (User= and Group=). They currently fail but this is masked by the '-f' option. I was able to fix this on my local system by (1) commenting out the ExecStartPre= statements and (2) moving them to a dependent service that runs as root. I guess this could also be accomplished with PermissionsStartOnly=true. Reproducible: Always Steps to Reproduce: 1. build up a system that uses sssd (fully-populated /etc/sssd/sssd.conf) 2. stop sssd 3. chmod 0700 /etc/sssd 4. chown root:sssd /etc/sssd 5. try to start sssd Actual Results: sssd does not start, it is not able to correctly re-own the files and directories it needs. Here is the update report from the most recent ostree transaction $ rpm-ostree db diff ostree diff commit from: rollback deployment (5796a4d9fbff9b2d0e28f34070e6958e0cfb5a1b3ab702fd1ed318ade3aa91ef) ostree diff commit to: booted deployment (f07128cd02dc40fbe578714f095140f44e5986f98902783d00bbd837a0ed06d6) Upgraded: cldr-emoji-annotation 1:46.1~beta2-1.fc41 -> 1:46.1-1.fc41 cldr-emoji-annotation-dtd 1:46.1~beta2-1.fc41 -> 1:46.1-1.fc41 ibus-typing-booster 2.27.1-1.fc41 -> 2.27.2-1.fc41 intel-vpl-gpu-rt 24.3.4-1.fc41 -> 24.4.4-1.fc41 libsss_certmap 2.10.0-2.fc41 -> 2.10.1-1.fc41 libsss_idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41 libsss_nss_idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41 libsss_sudo 2.10.0-2.fc41 -> 2.10.1-1.fc41 libva-intel-media-driver 24.3.4-1.fc41 -> 24.4.4-1.fc41 libvpl 1:2.13.0-1.fc41 -> 1:2.14.0-1.fc41 libxml2 2.12.8-2.fc41 -> 2.12.9-1.fc41 openjpeg 2.5.3-1.fc41 -> 2.5.3-2.fc41 setup 2.15.0-5.fc41 -> 2.15.0-8.fc41 sssd-client 2.10.0-2.fc41 -> 2.10.1-1.fc41 sssd-common 2.10.0-2.fc41 -> 2.10.1-1.fc41 sssd-kcm 2.10.0-2.fc41 -> 2.10.1-1.fc41 sssd-krb5-common 2.10.0-2.fc41 -> 2.10.1-1.fc41 sssd-ldap 2.10.0-2.fc41 -> 2.10.1-1.fc41 sssd-nfs-idmap 2.10.0-2.fc41 -> 2.10.1-1.fc41 -- 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=2334868 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 27

2025

2024

2023

2022

2021

2020

Sssd-maintainers February 2025