Bug 1012343
| Summary: | Thread issue in glibc can cause the application to not get any identity information | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Kaushik Banerjee <kbanerje> | ||||||
| Component: | glibc | Assignee: | Carlos O'Donell <codonell> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Sergey Kolosov <skolosov> | ||||||
| Severity: | unspecified | Docs Contact: | Mark Flitter <mflitter> | ||||||
| Priority: | unspecified | ||||||||
| Version: | 6.5 | CC: | 1105789050, ashankar, codonell, fweimer, jhrozek, mcermak, mflitter, mnewsome, msebor, ohudlick, pfrankli, rhbugs, skolosov | ||||||
| Target Milestone: | rc | Keywords: | Patch | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | glibc-2.12-1.207.el6 | Doc Type: | Bug Fix | ||||||
| Doc Text: |
Fix for handling any open file descriptors in the event of thread cancellation
The use of POSIX thread cancellation could cause glibc to improperly handle open file descriptors, particularly those held open when processing identity information.
To correct this and ensure that functions like getpwuid_r complete, even when the thread is being cancelled, the library calls have been changed to correctly handle open file descriptors in any call from the exec family of functions.
|
Story Points: | --- | ||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2017-03-21 10:34:20 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1361283 | ||||||||
| Attachments: |
|
||||||||
|
Description
Kaushik Banerjee
2013-09-26 10:23:53 UTC
Just to add further context, this issue was discovered when QE's tests that Kaushik added above started failing. The tests were initially written to test a mutex lock issue in the sssd client and were passing in previous RHEL-6 updates. So is there any chance the code could have regressed between 6.4 and 6.5 perhaps? btw the sssd upstream bug was https://fedorahosted.org/sssd/ticket/1460 fixed by https://git.fedorahosted.org/cgit/sssd.git/commit/?id=86b61156743b7ebdc049450a6f88452890fd9a61 Ok, the good news is that I've duplicated the bug on an old 6.1 VM I had lying around, so this is not a regression. The bad news is that we have at least two bugs here: the deadlocks we get are different depending on whether or not nscd is running. The former is fixed by upstream commit 312be3f9, that (among other things) adds the "c" option to various fopen calls, so that stdio stream operations on /etc/passwd et al are not cancellation points: then the lock used to guard the data structures that control the internal setent/getent calls won't leak, for no other cancellation point is exercised. The latter turns out to be a bug in the testcase. When nscd is disabled, every time we call getpwuid_r, we attempt to connect to the nscd socket, and connect is a mandatory cancellation point. When nscd is enabled, however, the first call makes the connection, and subsequent calls don't call any cancellation points, so the test loops forever, because getpwuid_r is an optional cancellation point, and glibc doesn't introduce an artificial cancellation point in it. Thus pthread_testcancel() needs to be taken out of the #ifdef/#endif block to fix this bug in the testcase. Upstream commit from comment 6: commit 312be3f9f5eab1643d7dcc7728c76d413d4f2640 Author: Ulrich Drepper <drepper> Date: Tue Nov 15 04:24:42 2011 -0500 Clean up internal fopen uses No need to ever not use c and e. Created attachment 1209871 [details] Tested patch. Attached patch posted for review: http://post-office.corp.redhat.com/archives/tools-patches/2016-September/msg00048.html Created attachment 1227440 [details]
tst-cancel-getpwuid_r.c
There is no reason the test for this issue should use sleep or yield, we have a perfectly acceptable semaphore implementation that guarantees that you are close as possible to issuing a getpwuid_r without all the overhead of sleeping.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2017-0680.html Oracle claims the patch was incorrect, causing memory corruption: https://blogs.oracle.com/wim/entry/oracle_linux_6_update_9 (In reply to Anssi Johansson from comment #21) > Oracle claims the patch was incorrect, causing memory corruption: > https://blogs.oracle.com/wim/entry/oracle_linux_6_update_9 Thanks, I filed the regression as bug 1437111. (In reply to Florian Weimer from comment #22) > (In reply to Anssi Johansson from comment #21) > > Oracle claims the patch was incorrect, causing memory corruption: > > https://blogs.oracle.com/wim/entry/oracle_linux_6_update_9 > > Thanks, I filed the regression as bug 1437111. I've closed 1437111 as a duplicate. I'm going to use bug 1437147 to track the fix and missing changes. |