Bug 1232702
| Summary: | gperftools: tcmalloc debug version uses hard-coded path /tmp/google.alloc | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Florian Weimer <fweimer> |
| Component: | gperftools | Assignee: | Paolo Bonzini <pbonzini> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.2 | CC: | huding, juzhang, knoel, michen, mrezanin, pbonzini, wquan, xfu, yama |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | gperftools-2.4-2.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-19 09:32:03 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: | 1227837 | ||
I checked the gperftools/gperftools-2.4/src/debugallocation.cc in both gperftools-2.4-1 and gperftools-2.4-2. The output is the same as comment 0: // Return the file descriptor we're writing a log to 955 static int TraceFd() { 956 static int trace_fd = -1; 957 if (trace_fd == -1) { // Open the trace file on the first call 958 trace_fd = open("/tmp/google.alloc", O_CREAT|O_TRUNC|O_WRONLY, 0666); 959 if (trace_fd == -1) { 960 trace_fd = 2; 961 TracePrintf(trace_fd, 962 "Can't open /tmp/google.alloc. Logging to stderr.\n"); 963 } ... Is it the correct results? Are you using "rhpkg prep"? I see the right result for gperftools-2.4-2. > The original reported problem still exists if the TCMALLOC_TRACE_FILE
> environment variable is not set. I find this change rather puzzling.
The point of the change is just to let multiple users do their own debugging without stumbling on someone else's /tmp/google.alloc, by either specifying TCMALLOC_TRACE_FILE or falling back to stderr. I didn't treat it as a vulnerability, just as a bug that occurs whenever /tmp/google.alloc exists and is owned by someone else.
According to comment10, comemnt11 and comment14. Set this issue as verified. Please let me know if need further testing from kvm qe side. Best Regards, Junyi 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/RHEA-2015-2293.html |
The debug version of tcmalloc opens a hard-coded file in /tmp. Arguably, this is not a vulnerability because it just affects debugging, but we should still fix this before shipping gperftools. // Return the file descriptor we're writing a log to static int TraceFd() { static int trace_fd = -1; if (trace_fd == -1) { // Open the trace file on the first call trace_fd = open("/tmp/google.alloc", O_CREAT|O_TRUNC|O_WRONLY, 0666); if (trace_fd == -1) { trace_fd = 2; TracePrintf(trace_fd, "Can't open /tmp/google.alloc. Logging to stderr.\n"); } …