Bug 438308

Summary: changes in rhel5.2 gcc caused gdb.base/prelink.exp to FAIL
Product: Red Hat Enterprise Linux 5 Reporter: Petr Muller <pmuller>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 5.2CC: ebenes, jakub, jan.kratochvil, ohudlick
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2008-0465 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-21 16:43:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
PASSing log
none
FAILing log
none
GDB testcase fix. none

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):
gcc-4.1.2-41.el5
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 
gcc-4.1.2-41.el5
gdb-6.5-37.el5

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

testcase log for

gcc-4.1.2-41.el5
gdb-6.5-37.el5

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:
http://qafiler.boston.redhat.com/redhat/nightly/RHEL5.2-Server-20080319.nightly/5/i386/os/

# runtest gdb.base/prelink.exp
...
Running ../../../gdb/testsuite/gdb.base/prelink.exp ...
prelink: Could not set security context for
/root/jkratoch/redhat/gdb-6.5-37.el5.src/gdb-6.5/build-i386-redhat-linux-gnu/gdb/testsuite/gdb.base/prelink.so:
Permission denied
prelink:
/root/jkratoch/redhat/gdb-6.5-37.el5.src/gdb-6.5/build-i386-redhat-linux-gnu/gdb/testsuite/gdb.base/prelink.so
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
./empty.so
prelink: Could not set security context for /root/jkratoch/redhat/empty.so:
Permission denied

setxattr("/root/jkratoch/redhat/empty.so.#prelink#.SdWpnf",
"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> 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.

http://rhn.redhat.com/errata/RHBA-2008-0465.html