Bug 138234 - signal handling bug in nss_ldap causes application failure
Summary: signal handling bug in nss_ldap causes application failure
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: nss_ldap
Version: 2
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-05 22:35 UTC by Erik Horn
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version: 220
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-25 20:35:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Erik Horn 2004-11-05 22:35:20 UTC
Depending on the environment the severity of this issue can range from
high to low.

Description of problem:

There is a signal handling bug in nss_ldap in versions <200 and
213-219. The bug in the library causes the SIGPIPE signal to become
unblocked even after the application has blocked the signal.

This can create all sorts of problems if the ldap server disconnects
the client application, ranging from denial of service conditions to
corruption of data, for any application that uses the library.

In my particular case, I have been using openldap for several years
with the option idletimeout set to disconnect idle ldap sessions.
After upgrading to FC2, using this option causes samba to disconnect
the client workstation unexpectedly, causing data loss.

How reproducible:

Easy to reproduce

Steps to Reproduce:
1. kill -13 (pid of smbd client process)
  
Actual results:

process dies

Expected results:

process should remain running becuase smbd blocks that signal.

Additional info:

This bug is documented as bug #173 at bugzilla.padl.com

I configured a test machine similiarily to my production machine.
After installing all the FC2 updates, I confirmed that the problem
still existed.

I then updated the nss_ldap to version 220 (from FC3test3, ignoring
dependencies). After restarting samba, the problem no longer existed.

Comment 1 Matthew Miller 2005-04-26 16:04:15 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 2 John Thacker 2006-10-25 20:35:04 UTC
Closing per lack of response.  Also note that FC1 and FC2 are no longer
supported even by Fedora Legacy.  If this still occurs on FC3 or FC4, please
assign to that version and Fedora Legacy.  If it still occurs on FC5 or FC6,
please reopen and assign to the correct version.

Sounds like updating to FC3 fixed it, though.


Note You need to log in before you can comment on or make changes to this bug.