January 2025 - Sssd-maintainers - Fedora mailing-lists

[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 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

[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

2025

2024

2023

2022

2021

2020

Sssd-maintainers January 2025