Hide Forgot
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.
Created attachment 298681 [details] PASSing log test log with gcc-4.1.2-41.el5 gdb-6.5-37.el5
Created attachment 298682 [details] FAILing log testcase log for gcc-4.1.2-41.el5 gdb-6.5-37.el5
sorry, comment 1 should state gcc-4.1.2-14.el5, not -41
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.
Fixed in /selinux-policy-2.4.6-126.el5.src.rpm
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
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).
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.
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.
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