- Sssd-maintainers - Fedora mailing-lists

[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 14 Mar '25

14 Mar '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 5

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

08 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 01 Feb '25

01 Feb '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 01 Feb '25

01 Feb '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 01 Feb '25

01 Feb '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

[Bug 2320042] New: [abrt] sssd-tools: set_component(): source_files.py:73:set_component:OSError
by bugzilla＠redhat.com 28 Jan '25

28 Jan '25

https://bugzilla.redhat.com/show_bug.cgi?id=2320042 Bug ID: 2320042 Summary: [abrt] sssd-tools: set_component(): source_files.py:73:set_component:OSError Product: Fedora Version: 41 Hardware: x86_64 Status: NEW Whiteboard: abrt_hash:a5a6dd78a14a8d86bce922d86636e1cb2da53ec6;VAR IANT_ID=workstation; Component: sssd Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: maxi(a)maxiicodes.dev 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 Version-Release number of selected component: sssd-tools-2.10.0-1.fc41 Additional info: reporter: libreport-2.17.15 kernel: 6.11.4-300.fc41.x86_64 cmdline: /usr/bin/python3 -sP /usr/libexec/sssd/sss_analyze error list cgroup: 0::/user.slice/user-1000.slice/user@1000.service/app.slice/app-cosmic-com.system76.CosmicAppList-3787.scope uid: 1000 reason: source_files.py:73:set_component:OSError executable: /usr/libexec/sssd/sss_analyze type: Python3 package: sssd-tools-2.10.0-1.fc41 runlevel: N 5 exception_type: OSError crash_function: set_component interpreter: python3-3.13.0-1.fc41.x86_64 Truncated backtrace: source_files.py:73:set_component:OSError Traceback (most recent call last): File "/usr/libexec/sssd/sss_analyze", line 5, in <module> sss_analyze.run() ~~~~~~~~~~~~~~~^^ File "/usr/lib/python3.13/site-packages/sssd/sss_analyze.py", line 107, in run analyzer.main() ~~~~~~~~~~~~~^^ File "/usr/lib/python3.13/site-packages/sssd/sss_analyze.py", line 102, in main args.func(args) ~~~~~~~~~^^^^^^ File "/usr/lib/python3.13/site-packages/sssd/modules/error.py", line 52, in print_error source.set_component(component, False) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.13/site-packages/sssd/source_files.py", line 73, in set_component raise IOError OSError Local variables in innermost frame: self: <sssd.source_files.Files object at 0x7f0cd2976e40> component: <Component.BE: 3> child: False domains: [] -- 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=2320042 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 7

[Bug 2338168] New: Mix of sssd and root user for dir /etc/sssd /etc/sssd/*
by bugzilla＠redhat.com 15 Jan '25

15 Jan '25

https://bugzilla.redhat.com/show_bug.cgi?id=2338168 Bug ID: 2338168 Summary: Mix of sssd and root user for dir /etc/sssd /etc/sssd/* Product: Fedora Version: 41 OS: Linux Status: NEW Component: sssd Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: terjeros(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-2.10.1-1.fc41 and later uses sssd as user for various files, however sssd.service includes this: ExecStartPre=/bin/chown -f -R root:sssd /etc/sssd while rpm package has: $ rpm -qvl sssd-common |grep /etc/sssd drwxr-x--- 2 sssd sssd 0 Dec 10 01:00 /etc/sssd drwxr-x--- 2 sssd sssd 0 Dec 10 01:00 /etc/sssd/conf.d drwxr-x--- 2 sssd sssd 0 Dec 10 01:00 /etc/sssd/pki -rw------- 1 sssd sssd 0 Dec 10 01:00 /etc/sssd/sssd.conf Please try to align this. Reproducible: Always -- 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=2338168 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 2

[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 02 Jan '25

02 Jan '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 22

[Bug 2334087] New: Capabilities related changes in sssd-2.10.1-2.fc42.x86_64 break SSSD in containers
by bugzilla＠redhat.com 02 Jan '25

02 Jan '25

https://bugzilla.redhat.com/show_bug.cgi?id=2334087 Bug ID: 2334087 Summary: Capabilities related changes in sssd-2.10.1-2.fc42.x86_64 break SSSD in containers Product: Fedora Version: rawhide OS: Linux Status: NEW Component: sssd Keywords: Regression Severity: medium Assignee: sssd-maintainers(a)lists.fedoraproject.org Reporter: adelton(a)fedoraproject.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 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/80a939719c9fd4226e7eefc0d3d93c494…. 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. -- 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=2334087 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2333529] New: unpacking of archive failed on file /var/lib/sss/mc: cpio: chown failed
by bugzilla＠redhat.com 27 Dec '24

27 Dec '24

https://bugzilla.redhat.com/show_bug.cgi?id=2333529 Bug ID: 2333529 Summary: unpacking of archive failed on file /var/lib/sss/mc: cpio: chown failed Product: Fedora Version: 41 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 While trying to upgrade a systemd-nspawn container from Fedora 40 to Fedora 41, I received the following error: Upgrading : sssd-common-2.10.0-2.fc41.x86_64 495/1223 error: unpacking of archive failed on file /var/lib/sss/mc: cpio: chown failed - No data available The container's /var/lib/sss/mc directory is ro-bind-mounted from the host system similar to what is described in the last post (dated 11/05/16 14:29) here: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.… Reproducible: Always Steps to Reproduce: 1. dnf upgrade --releasever=41 Actual Results: Failed: sssd-common-2.9.5-1.fc40.x86_64 sssd-common-2.10.0-2.fc41.x86_64 Error: Transaction failed Expected Results: Transaction succeeded -- 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=2333529 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 11

2025

2024

2023

2022

2021

2020

Sssd-maintainers