SIGPIPE not caught in do_atfork_child()

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Has this patch gone upstream at all, please? We'd prefer to not have to maintain patches indefinitely.

AFAICT it seems this has been fixed upstream for libnss-ldap 266 (http://bugzilla.padl.com/show_bug.cgi?id=414)

and then the project died? (it hasn't done an update since 2010.

Note, I emailed upstream about the 266 version coming out/ project status.

The author posted the source code of nss_ldap 266 (including the fix for this bug) to https://github.com/PADL/nss_ldap

FWIW, I tried to recreate this with the testcase shown here: http://bugzilla.padl.com/show_bug.cgi?id=414 on both trusty (264-2.2ubuntu4.14.04.1) and wily (265-3ubuntu2), but testcase passed fine (even ran in loop). Neither package has the fix from upstream.

So, I'll probably rebuild libnss-ldap from source and make sure its even triggering the buggy code path next.

Another reproducer script to try. Make sure you don't have NSCD installed.

Thanks Bryan, verified NCSD isn't running. New script passes just fine for me too; no segfault seen with either test reproducer. Additionally, verified that I'm pulling expected entry results from my ldap server.

Interestingly rebuilding 265-3ubuntu2 with DEBUG enabled... the code path of do_child_atfork() isn't even hitting (no debug statements from that function emitted). do_child_atfork() is where the proposed fix touches.

Additionally, I backleveled my trusty VM to 264-2.2ubuntu4. The testreproducer didn't segfault there either.

@BryanQuigley: Are you able to reproduce this bug? I may have to rely up on you or the reporter to test if so. The fix is straight-forward/upstream.. I'm just loathe to fix something that i can't prove fixes anything..

@jgrimm
If I had an environment for testing it, it's long since been deleted. I worked it on behalf of someone else, they've since moved to sssd. I think going forward if we can get version 266 for 16.04 that would be fine..

@brianquigley, Thanks for responding. Indeed, may have to wait unless I can find someone that can reproduce and/or speak to impacting them rather than theoretical.

FWIW, debian sid has 265.. and does not have a patch with the fix yet either.

@jon.grimm

I can reproduce after I set up LDAP server and client to use StartTLS.
In plain setup, no write to non-connected socket is issued in the
atfork handlers of child process, so no SIGPIPE is raised.

On Wed, Aug 26, 2015 at 7:45 PM, Jon Grimm <email address hidden> wrote:
> @brianquigley, Thanks for responding. Indeed, may have to wait unless I
> can find someone that can reproduce and/or speak to impacting them
> rather than theoretical.
>
> FWIW, debian sid has 265.. and does not have a patch with the fix yet
> either.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1397250
>
> Title:
> SIGPIPE not caught in do_atfork_child()
>
> Status in nss_ldap:
> Fix Released
> Status in libnss-ldap package in Ubuntu:
> Triaged
>
> Bug description:
> Ubuntu version: Ubuntu 14.04.1 LTS
> Package version: libnss-ldap_264-2.2ubuntu4
>
> If a process using libnss-ldap calls fork() and SIGPIPE was blocked, the atfork() handler in the child process failed to catch the SIGPIPE as it was supposed to do, that is in the call to do_close_no_unbind(). So that, the uncaught SIGPIPE will be eventually
> delivered when the child unblocks signals. This usually make the child process die unexpectedly.
>
> I found a well-known Linux vendor fixed this issue with the following
> patch. This unblocks the SIGPIPE before calling do_close_no_unbind()
> and restores the original sigmask afterwards:
>
> diff -up nss_ldap/ldap-nss.c nss_ldap/ldap-nss.c
> --- nss_ldap/ldap-nss.c 2009-12-07 20:57:33.000000000 -0500
> +++ nss_ldap/ldap-nss.c 2009-12-07 20:58:56.000000000 -0500
> @@ -532,8 +532,13 @@
> static void
> do_atfork_child (void)
> {
> + sigset_t unblock, mask;
> debug ("==> do_atfork_child");
> + sigemptyset(&unblock);
> + sigaddset(&unblock, SIGPIPE);
> + sigprocmask(SIG_UNBLOCK, &unblock, &mask);
> do_close_no_unbind ();
> + sigprocmask(SIG_SETMASK, &mask, NULL);
> _nss_ldap_leave ();
> debug ("<== do_atfork_child");
> }
>
> I'd like to see this patch applied.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nss-ldap/+bug/1397250/+subscriptions

Ah. Great! Will see if StartTLS can help me trigger it! Thanks @marcello-bancasio

Please push upstream the new 266 version from the author's git repository as this bug has serious drawbacks like breaking postgresql installation on all our servers using it.

The 266 version is about 6 years old and contains a lot of bug fixes, I think it would be worth to use it.

https://github.com/PADL/nss_ldap

Thank you,
Sandro

Sadly, just getting back to this. Testing with StartTLS as per suggestion.

I can reproduce this with trusty client, but not with yakkety. I've not tested with xenial yet. This baffles me a bit as I don't see the proposed fix in the yakkety source, but maybe something else comes into play with systemd or other. Next I'll test that the referenced patch actually fixes the reproduced bug.

Minor update.

1) I was not able to reproduce on xenial (libnss-ldap 265-3ubuntu2)
2) I built a ppa with a trusty upgrade to 265-3ubuntu2 codebase.. interestingly, I was unable to reproduce. I find this odd (still) because the proposed fix is not in that code base.

I still need to.

Rebuild current trusty with the suggested patch, and see how that affects the reproducer. Ran into my first experience with cdbs + patchsys-quilt.mk, so didn't quite get that accomplished today. Maybe tonite or tomorrow.

OK, built trusty's libnss-ldap with the patch referenced by the bug submitter. Indeed, it too resolved the issue.

So to summarize:
1) Only trusty's libnss-ldap seems to fail.
2) The bug seems fixable by any of the following:
  a) patch in comment #1, or
  b) updating trusty to xenial/yakkety libnss-ldap (with the caveat that I have no clue as to why this fixes it!)
  c) updating to upstream, which also has the patch referenced in comment #1.

I'm leaning towards a because its intentionally the upstream fix for the bug, and even if I can't reproduce xenial/yakkety, it seems a safe enough fix (I will test this assumption) to apply there too. I also think the amount of changes in b) & c) are too numerous to safely put back to trusty.

Consulted with racb, my plan of attack will be to SRU the patch only into trusty (with push to zesty first) for now. If someone else can reproduce the bug on xenial and/or yakkety, AND is will to test fix, I'll SRU into those releases correspondingly.

Zesty debdiff for Sponsorship please.

How I test:

1) Configure slapd (server) and libnss-ldap/ldap-utils (client)
Note: Ubuntu Server Guide is a godsend to a newbie. https://help.ubuntu.com/lts/serverguide/openldap-server.html

2) Configure slapd (server) to serve up desired /etc/hosts information
Note: The Arch folks have some good examples of this:
https://wiki.archlinux.org/index.php/LDAP_Hosts

3) Configure nsswitch to use ldap
- Add 'ldap' to the 'hosts' entry in /etc/nsswitch
NOTE: make sure to disable 'nscd'!

4) Test libldap-nss/ldap working as expected:
$ getent hosts
-Should see the hosts as entered into slapd added now

5) Now configure for StartTLS
Again see Ubuntu documentation:
https://help.ubuntu.com/lts/serverguide/openldap-server.html

6) Retest to make sure still working
$getent hosts
Note: You can verify that StartTLS is working by enabling logging on slapd and then,
$ grep STARTTLS /var/log/syslog

Note: log enabling for slapd:
http://blog.suretecsystems.com/archives/163-OpenLDAP-Quick-Tips-Change-loglevels-on-the-fly!.html

, i enabled 'all'

You should see a STARTTLS connection every time you call 'getent hosts', if its working as expected. If you are hardcore, you can also configure the server to _only_ accept STARTTLS, but I'll leave that as an exercise for the reader.

7) Now you can test the bug! (Note: I modified the testcase provided to use getbyhostname)
ubuntu@tldapclient:~$ ./testhosts.pl
Parent!
Parent wake!
Done!

^^ Note the lack of "Child!", because the child has segfaulted.

8) With the fix:
ubuntu@tldapclient:~$ ./testhosts.pl
Parent!
Child!
Done!
Parent wake!
Done!

^^ Note the child survived. \o/

Adding DEP3 headers

This bug was fixed in the package libnss-ldap - 265-3ubuntu3

---------------
libnss-ldap (265-3ubuntu3) zesty; urgency=medium

   * Fix from upstream:
     + SIGPIPE not caught in do_atfork_child() (LP: #1397250)

 -- Jon Grimm <email address hidden> Wed, 19 Oct 2016 16:01:16 -0500

Adding debdiff for trusty.

Hello Marcello, or anyone else affected,

Accepted libnss-ldap into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libnss-ldap/264-2.2ubuntu4.14.04.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Verified fixed with trusty-proposed.

Tested version libnss-ldap_264-2.2ubuntu4.14.04.2 on amd64 from trusty-proposed.

ubuntu@tldapclient:~$ ./testhosts.pl
Parent!
Child!
Done!
Parent wake!
Done!

seems like the changes have uploaded so unsubscribing the sponsors

This bug was fixed in the package libnss-ldap - 264-2.2ubuntu4.14.04.2

---------------
libnss-ldap (264-2.2ubuntu4.14.04.2) trusty; urgency=medium

   * Fix from upstream:
     + SIGPIPE not caught in do_atfork_child() (LP: #1397250)

 -- Jon Grimm <email address hidden> Wed, 19 Oct 2016 17:29:10 -0500

The verification of the Stable Release Update for libnss-ldap has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Thank you. libnss-ldap-264-2.2ubuntu4.14.04.2 fixed the issue.

On Thu, Nov 10, 2016 at 7:12 PM, Brian Murray <email address hidden> wrote:
> The verification of the Stable Release Update for libnss-ldap has
> completed successfully and the package has now been released to
> -updates. Subsequently, the Ubuntu Stable Release Updates Team is being
> unsubscribed and will not receive messages about this bug report. In
> the event that you encounter a regression using the package from
> -updates please report a new bug using ubuntu-bug and tag the bug report
> regression-update so we can easily find any regressions.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1397250
>
> Title:
> SIGPIPE not caught in do_atfork_child()
>
> Status in nss_ldap:
> Fix Released
> Status in libnss-ldap package in Ubuntu:
> Fix Released
> Status in libnss-ldap source package in Trusty:
> Fix Released
> Status in libnss-ldap source package in Xenial:
> Won't Fix
> Status in libnss-ldap source package in Yakkety:
> Won't Fix
>
> Bug description:
> [Impact]
>
> * If a process using libnss-ldap calls fork() and SIGPIPE was blocked,
> the atfork() handler in the child process failed to catch the SIGPIPE
> as it was supposed to do, that is in the call to do_close_no_unbind().
> So that, the uncaught SIGPIPE will be eventually delivered when the
> child unblocks signals. This usually make the child process die
> unexpectedly.
>
> * This is only reproducible when ldap is configured for STARTTLS.
>
> * Upstream fix has been long integrated.
>
> [Test Case]
>
> * See https://bugs.launchpad.net/ubuntu/trusty/+source/libnss-
> ldap/+bug/1397250/comments/19
>
>
> [Regression Potential]
>
> * Fix has been upstream since 2010, and limited to path of child
> forking, and SIGPIPE is blocked. No consequent bugs or regressions
> in the upstream blamed on this change.
>
>
> [Other Info]
>
> * I'm currently limiting my SRU to trusty, as I'm unable to
> recreate the bug on xenial. Even so, I have tested the fixed
> code on xenial to ensure there was no regression with the testcase.
>
> * Will look at fixing xenial too, IFF someone comes forward able to
> reproduce the bug/validate the fix.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nss-ldap/+bug/1397250/+subscriptions