Learn more about these different git repos.
Other Git URLs
https://bugzilla.redhat.com/show_bug.cgi?id=826192 (Red Hat Enterprise Linux 6)
Description of problem: Occasionally, sssd_pam leaks file descriptors to /var/lib/sss/pipes/private/pam which causes logins to fail and cron jobs to not launch. I noticed that it happens after a user closes their ssh session, then attempts to log back in using a password. Normally the reconnect works fine, but it randomly fails. After sssd_pam gets borked, each failed ssh attempt leads to another leaked file descriptor. In our case, it's an automated process that keeps retrying, and eventually we bump up against the open file descriptor limit. I have a debug sssd_pam log, /var/log/secure log, and an strace of sssd_pam when this issue occurred, but due to their sensitive nature, I can't post them until this bug is marked private. Version-Release number of selected component (if applicable): Occurs in both sssd-1.5.1-66.el6_2.3.x86_64 and sssd-1.8.0-22.el6.x86_64 How reproducible: Not sure yet. It's sporadic, so I haven't been able to create a reproducer. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Fields changed
blockedby: => blocking: => coverity: => feature_milestone: => milestone: NEEDS_TRIAGE => SSSD 1.9.0 tests: => 0 testsupdated: => 0 upgrade: => 0
The NSS and PAM pipes use common code to handle pipes. Due to NSS requirements to handle enumerations we defaulted to leave connections open by default.
However in the PAM case we do not depend on a client connection to keep client-bound state so we could avoid leaks by simply always closing the connection after each PAM operation.
Given authentication is usually an inherently slow operation and is also performed rarely in most cases, the overhead of re-opening the pipe should be lost in the noise in most case.
In case the overhead is not minimal for some special authentication hubs that have a higher rate of PAM requests we could conceivably provide a way to indicate connections should be reused though an environment variable.
owner: somebody => pbrezina status: new => assigned
patch: 0 => 1
milestone: SSSD 1.9.0 => SSSD 1.9.1
It is unclear whether we still need this enhancement after dd94e9c. Putting back to NEEDS_TRIAGE for discussion.
milestone: SSSD 1.9.1 => NEEDS_TRIAGE patch: 1 => 0
We discussed the proposal some more with Simo and Sumit and decided for a different approach (two actually). They are being tracked in #1569 and #1570.
resolution: => wontfix status: assigned => closed
design: => design_review: => 0 fedora_test_page: => milestone: NEEDS_TRIAGE => SSSD 1.9.2
Metadata Update from @sgallagh: - Issue assigned to pbrezina - Issue set to the milestone: SSSD 1.9.2
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/2403
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.