SSSD / sssd

#3106 ldap_child does not remove temporary files when it's killed with SIGTERM
Closed: Fixed Opened by jhrozek.

Closed: Fixed
Reopen Issue

The ldap_child helper process creates a temporary file and then acquires credentials, which is a synchronous operation. If that takes more than a configured timeout, the parent (sssd_be) kills the child process with SIGTERM. But if the child process is killed, we don't remove the temporary file. We need to fix that..

Fields changed

owner: somebody => pcech

I think we didn't discuss milestone, but IMO this ticket belongs to the stable version, because it can potentially flood the filesystem with temporary files.

milestone: NEEDS_TRIAGE => SSSD 1.13.5

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1361567

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=1361567 1361567]

Fields changed

status: new => assigned

Fields changed

patch: 0 => 1
  • master:
    • 864cdac4c7fbe768d768da5e01b7518eb02836d9
    • b9a0959c274367dcf69bba6b0a942a1682c74f73
    • 4313147ab4214037900cbb3ced8a03e492bff02c

sssd-1-13:
- 41afbb6b86d592be2d0f831dbea4f4d92b73cdb5
- 09403b66fa73d294f38ddd4afa4d32eaf8d92087
- 96e135a1b42c565c257e525c1eb04751058e6836

resolution: => fixed
status: assigned => closed

Metadata Update from @jhrozek:
- Issue assigned to pcech
- Issue set to the milestone: SSSD 1.13.5

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4139

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.
Metadata
None
None
None
Normal
0
1
0
0
0
defect
SSSD
1.14.0
None
https://bugzilla.redhat.com/show_bug.cgi?id=1361567
0
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.