Bug 1369130 - nss_sss should not link against libpthread
Summary: nss_sss should not link against libpthread
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Hrozek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-22 14:21 UTC by Florian Weimer
Modified: 2020-05-02 18:27 UTC (History)
10 users (show)

Fixed In Version: sssd-1.14.2-2.fc23 sssd-1.14.2-2.fc25 sssd-1.14.2-2.fc24
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-17 00:23:46 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4189 0 None None None 2020-05-02 18:27:55 UTC
Sourceware 20500 0 None None None 2016-08-22 14:21:07 UTC

Description Florian Weimer 2016-08-22 14:21:07 UTC
/usr/lib64/libnss_sss.so.2 in sssd-client-1.13.4-4.fc24.x86_64 is linked against libpthread.  This causes problems when static binaries attempt to use NSS-based functions:

  https://sourceware.org/bugzilla/show_bug.cgi?id=20500

It also increases the risk for symbol collisions with the application binary.

What libpthread functionality do you *really* need which is not in libc.so.6?

Comment 1 Jakub Hrozek 2016-08-22 14:35:24 UTC
See https://github.com/SSSD/sssd/blob/master/src/sss_client/common.c#L1067 and onwards, we use mutexes, including robust mutexes. Does libc provide all these even w/o linking to -lpthread?

Comment 2 Florian Weimer 2016-08-22 15:27:01 UTC
(In reply to Jakub Hrozek from comment #1)
> See https://github.com/SSSD/sssd/blob/master/src/sss_client/common.c#L1067
> and onwards, we use mutexes, including robust mutexes. Does libc provide all
> these even w/o linking to -lpthread?

Thanks.  What is the scenario which will result in an EOWNERDEAD error for these robust mutexes?  All these mutexes look process-local, and any event which would trigger EOWNERDEAD would terminate the process, and the mutex would be gone as well.

Plain mutexes are available without libpthread.  But process-shared mutexes (both of the robust and non-robust variant) will not work without linking against libpthread.

Comment 3 Jakub Hrozek 2016-08-22 15:40:37 UTC
backtracking git history shows the robust mutexes were introduced in commmit 86b61156743b7ebdc049450a6f88452890fd9a61:
https://github.com/SSSD/sssd/commit/86b61156743b7ebdc049450a6f88452890fd9a61
which links to:
https://fedorahosted.org/sssd/ticket/1460

where the reporter gives some explanation and a reproducer program. It's been some time, so I'm not sure I remember the issue 100%, but I guess robust mutexes were the only solution I could come up with at that time..

Comment 4 Florian Weimer 2016-08-22 19:49:56 UTC
(In reply to Jakub Hrozek from comment #3)
> backtracking git history shows the robust mutexes were introduced in commmit
> 86b61156743b7ebdc049450a6f88452890fd9a61:
> https://github.com/SSSD/sssd/commit/86b61156743b7ebdc049450a6f88452890fd9a61
> which links to:
> https://fedorahosted.org/sssd/ticket/1460
> 
> where the reporter gives some explanation and a reproducer program. It's
> been some time, so I'm not sure I remember the issue 100%, but I guess
> robust mutexes were the only solution I could come up with at that time..

The fix is likely wrong.  It does release the lock, but you end up with whatever internal state you had at the point of cancellation.  If that is not fully consistent, an application which has canceled a NSS operation will experience rather subtle bugs.

There also seem to be resource leaks, e.g. sss_cli_recv_rep could leak the buffer if cancellation happens after the malloc call.

If you do not want to make the entire code cancellation-safe, you should defer cancellation on entry to nss_sss.  Or maybe we should change glibc so that it does that automatically for you.  I don't think many of the existing NSS modules are written with cancellation in mind.

Comment 5 Lukas Slebodnik 2016-08-22 19:57:08 UTC
(In reply to Florian Weimer from comment #4)
> (In reply to Jakub Hrozek from comment #3)
> > backtracking git history shows the robust mutexes were introduced in commmit
> > 86b61156743b7ebdc049450a6f88452890fd9a61:
> > https://github.com/SSSD/sssd/commit/86b61156743b7ebdc049450a6f88452890fd9a61
> > which links to:
> > https://fedorahosted.org/sssd/ticket/1460
> > 
> > where the reporter gives some explanation and a reproducer program. It's
> > been some time, so I'm not sure I remember the issue 100%, but I guess
> > robust mutexes were the only solution I could come up with at that time..
> 
> The fix is likely wrong.  It does release the lock, but you end up with
> whatever internal state you had at the point of cancellation.  If that is
> not fully consistent, an application which has canceled a NSS operation will
> experience rather subtle bugs.
> 
> There also seem to be resource leaks, e.g. sss_cli_recv_rep could leak the
> buffer if cancellation happens after the malloc call.
> 
> If you do not want to make the entire code cancellation-safe, you should
> defer cancellation on entry to nss_sss.  Or maybe we should change glibc so
> that it does that automatically for you.  I don't think many of the existing
> NSS modules are written with cancellation in mind.

The commit is quite an old. If would be better to comment git master
https://git.fedorahosted.org/cgit/sssd.git/tree/src/sss_client/common.c#n1081
I didn't compare them :-)

Comment 6 Florian Weimer 2016-08-22 20:05:11 UTC
(In reply to Lukas Slebodnik from comment #5)
> The commit is quite an old. If would be better to comment git master
> https://git.fedorahosted.org/cgit/sssd.git/tree/src/sss_client/common.c#n1081
> I didn't compare them :-)

My comment 4 was based on master (well, fe25b17660d5aed5b388a23c0ad34425fe728434).

Comment 7 Simo Sorce 2016-08-22 20:59:12 UTC
Florian, I think we should defer cancelation, do you have pointers (or even apatch :-) so we get it right ?

Simo.

Comment 8 Florian Weimer 2016-08-29 07:47:43 UTC
(In reply to Simo Sorce from comment #7)
> Florian, I think we should defer cancelation, do you have pointers (or even
> apatch :-) so we get it right ?

I'm not familiar with cancellation, but I expect that this will work:

  int old_state;
  pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &old_state);
  
  /* Code which runs with cancellation disabled.  */

  pthread_setcancelstate (old_state, &old_state);

This preserves the old state.

Comment 9 Jakub Hrozek 2016-08-29 09:05:06 UTC
Thank you for the idea, I will clone the bug upstream so that someone can take a stab at implementing this.

Comment 10 Jakub Hrozek 2016-08-29 09:07:38 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/3156

Comment 11 Lukas Slebodnik 2016-08-29 10:12:09 UTC
Does ticket #3156 cover just a "defer cancelation"?

or in another words; what do we want to do with this BZ in fedora?
Can we avoid linking with lipthread?
Does it requires some work on glibc side to for removing linking with pthread?

Comment 12 Florian Weimer 2016-08-29 11:01:05 UTC
(In reply to Lukas Slebodnik from comment #11)
> Does ticket #3156 cover just a "defer cancelation"?

I don't know.

> or in another words; what do we want to do with this BZ in fedora?
> Can we avoid linking with lipthread?
> Does it requires some work on glibc side to for removing linking with
> pthread?

If you use regular mutexes instead of robust mutexes, then you should be able to stop linking against libpthread.  Some <pthread.h> functionality is provided by libc as well.

Comment 13 Lukas Slebodnik 2016-11-24 11:58:22 UTC
master:
* d2f93542650c2f9613043acfa8e2f368972a70cd

Comment 14 Fedora Update System 2016-12-13 20:08:00 UTC
sssd-1.14.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-66bc868b6e

Comment 15 Fedora Update System 2016-12-13 20:10:00 UTC
sssd-1.14.2-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b04d690b49

Comment 16 Fedora Update System 2016-12-13 20:11:51 UTC
sssd-1.14.2-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b0d27da617

Comment 17 Fedora Update System 2016-12-15 02:28:15 UTC
sssd-1.14.2-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b0d27da617

Comment 18 Fedora Update System 2016-12-15 05:03:03 UTC
sssd-1.14.2-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b04d690b49

Comment 19 Fedora Update System 2016-12-15 05:06:28 UTC
sssd-1.14.2-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-66bc868b6e

Comment 20 Fedora Update System 2016-12-17 00:23:46 UTC
sssd-1.14.2-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2016-12-19 23:22:42 UTC
sssd-1.14.2-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 22 Fedora Update System 2016-12-22 18:18:13 UTC
sssd-1.14.2-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.


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