/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?
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?
(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.
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..
(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.
(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 :-)
(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).
Florian, I think we should defer cancelation, do you have pointers (or even apatch :-) so we get it right ? Simo.
(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.
Thank you for the idea, I will clone the bug upstream so that someone can take a stab at implementing this.
Upstream ticket: https://fedorahosted.org/sssd/ticket/3156
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?
(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.
master: * d2f93542650c2f9613043acfa8e2f368972a70cd
sssd-1.14.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-66bc868b6e
sssd-1.14.2-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b04d690b49
sssd-1.14.2-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b0d27da617
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
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
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
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.
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.
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.