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