Bug 438308 - changes in rhel5.2 gcc caused gdb.base/prelink.exp to FAIL
Summary: changes in rhel5.2 gcc caused gdb.base/prelink.exp to FAIL
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy-targeted   
(Show other bugs)
Version: 5.2
Hardware: All Linux
Target Milestone: rc
: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2008-03-20 10:59 UTC by Petr Muller
Modified: 2016-09-20 02:04 UTC (History)
4 users (show)

Fixed In Version: RHBA-2008-0465
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 16:43:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
PASSing log (3.67 KB, text/plain)
2008-03-20 11:00 UTC, Petr Muller
no flags Details
FAILing log (3.47 KB, text/plain)
2008-03-20 11:04 UTC, Petr Muller
no flags Details
GDB testcase fix. (1.42 KB, patch)
2008-03-21 20:25 UTC, Jan Kratochvil
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0465 normal SHIPPED_LIVE selinux-policy bug fix update 2008-05-20 14:36:31 UTC

Description Petr Muller 2008-03-20 10:59:02 UTC
Description of problem:

When testing tools errata for RHEL5.2, I discovered that after updating to 
candidate gcc (gcc-4.1.2-41.el5), gdb's internal testsuite test gdb.base/
prelink.exp started to FAIL (PASS previously). This occurs with both rhel5.1 
and rhel5.2 candidate gdb (gdb-6.5-25.el5_1.1 and gdb-6.5-37.el5), so the 
changes in gcc seem to be the causing factor.

The test is trying to guess if the different address of .dynamic section is 
caused by prelink. 

Version-Release number of selected component (if applicable):
gdb-6.5-25.el5_1.1 and gdb-6.5-37.el5

How reproducible:
always (at least for i386)

Steps to Reproduce:
1. install gdb-6.5-37.el5 src.rpm and apply gcc erratum (4.1.2-41.el5)
2. cd /usr/src/redhat/BUILD/gdb-6.5/gdb/testsuite
3. runtest --tool=gdb gdb.base/prelink.exp
Actual results:
Test fails. GDB doesn't emit this warning which is expected by testcase:

warning: .dynamic section for "/usr/src/redhat/BUILD/gdb-6.5/gdb/testsuite/
gdb.base/prelink.so" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations

Expected results:
Test passes.

Additional info:
I know that this could be a bug in gdb (or even the testcase) as well, but the 
changes were introduced in gcc so I filed it for gcc. I don't know if this is 
present on other arches, I have relevant results only for i386 and ia64 where 
prelink is not present.

Comment 1 Petr Muller 2008-03-20 11:00:43 UTC
Created attachment 298681 [details]
PASSing log

test log with 

Comment 2 Petr Muller 2008-03-20 11:04:18 UTC
Created attachment 298682 [details]
FAILing log

testcase log for


Comment 3 Petr Muller 2008-03-20 11:05:38 UTC
sorry, comment 1 should state gcc-4.1.2-14.el5, not -41

Comment 4 Jan Kratochvil 2008-03-20 15:51:14 UTC
Tested on:

# runtest gdb.base/prelink.exp
Running ../../../gdb/testsuite/gdb.base/prelink.exp ...
prelink: Could not set security context for
Permission denied
does not have .gnu.prelink_undo section

`setenforce 0' "fixes" this problem.

But it behaves randomly/unreproducively.  Not sure if it is related to whether
auditd is running - IMO I also fixed the problem by `service auditd start'.

Reproducer (but in some machine mood it works):

# touch empty.c; gcc -o empty.so -shared -fPIC -Wall empty.c; prelink -qNR
prelink: Could not set security context for /root/jkratoch/redhat/empty.so:
Permission denied

"security.selinux"..., "root:object_r:user_home_t:s0", 29, 0) = -1 EACCES
(Permission denied)
write(2, "prelink: ", 9) = 9
write(2, "Could not set security context f"..., 65) = 65

No selinux messages in the system log found.

Comment 5 Daniel Walsh 2008-03-20 16:01:20 UTC
Fixed in /selinux-policy-2.4.6-126.el5.src.rpm

Comment 6 Petr Muller 2008-03-21 09:48:30 UTC
ad comment 4: that is IMO different issue. My tests were run with permissive 
mode and the only difference between PASS and FAIL is the version of gcc as 
stated on comment 0

Comment 7 Jan Kratochvil 2008-03-21 20:21:07 UTC
For the selinux part:

(In reply to comment #5)
> Fixed in /selinux-policy-2.4.6-126.el5.src.rpm

I do not see a %changelog entry for it but the files changed there for prelink:

* Tue Mar 11 2008 Dan Walsh <dwalsh@redhat.com> 2.4.6-126
- Allow lvm to create fifo_file
- Fix building of policy modules with Makefile
Resolves: #438234

And I can confirm it no longer fails during my attempt (although it was not
always reproducible even before).

Comment 8 Jan Kratochvil 2008-03-21 20:25:25 UTC
Created attachment 298807 [details]
GDB testcase fix.

For the GDB part:

It is only a testcase problem, no need for a RHEL-5.2 GDB respin.
Explanation to be possibly approved by Jakub:

`--no-exec-shield' is for i386 where prelink in the exec-shield mode is 
forced to push all the libraries tight together to fit into the first two
memory areas (either the ASCII Shield area or at least below the executable).
In this case its -R option cannot be applied and we falsely FAIL here as if 
the system is already prelinked prelink has no choice how to randomize the
single new unprelinked library address without wasting the first one/two
memory areas.  We do not care of the efficiency of loading such resulting
exec-shield unfriendly prelinked library.

Comment 9 Daniel Walsh 2008-03-21 23:08:59 UTC
THe change was to make prelink and unconfined app,  Since it can currently
rewrite every executable on the system, having it confined makes no sense.  It
has been unconfined in F7, F8, F9

Plus people expect prelink to be able to read every directory on the system
since they could put an executable anywhere.

Comment 15 errata-xmlrpc 2008-05-21 16:43:12 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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