Bug 747592

Summary: segfault message supressed with su -c
Product: Red Hat Enterprise Linux 6 Reporter: Karel Volný <kvolny>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED ERRATA QA Contact: Tomas Dolezal <todoleza>
Severity: low Docs Contact:
Priority: medium    
Version: 6.2CC: azelinka, ooprala, ovasik, pandrade, prc, todoleza
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: Wrong propagation of signals from child process. Consequence: Core dump information is not propagated/shown in the parent process and su return value is wrong. Fix: Signal propagation from child was fixed and return values from su corrected. Result: Core dump message from child process is no longer ignored and su returns correct exit values.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 20:54:41 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:

Description Karel Volný 2011-10-20 12:49:19 UTC
Description of problem:
If I try to run a single command via su, and the program crashes, I don't get the segfault message echoed on stderr with bash.

Version-Release number of selected component (if applicable):
bash-4.1.2-8.el6

How reproducible:
always

Steps to Reproduce:
export LANG=C
pushd /tmp
cat << EOF > kaboom.c
main () {                                                                                                                                                              
    int *p;                                                                                                                                                            
    *p = 0;                                                                                                                                                            
}
EOF
cc -o kaboom kaboom.c
echo "1) non login BASH"
su -s /bin/bash -c "/tmp/kaboom" ; echo $?
echo "2) non login TCSH"
su -s /bin/tcsh -c "/tmp/kaboom" ; echo $?
echo "3) login BASH"
su -s /bin/bash -l -c "/tmp/kaboom" ; echo $?
echo "4) login TCSH"
su -s /bin/tcsh -l -c "/tmp/kaboom" ; echo $?
rm -f kaboom kaboom.c
popd

  
Actual results:
1) non login BASH
139
2) non login TCSH
Segmentation fault
139
3) login BASH
139
4) login TCSH
Segmentation fault
139


Expected results:
1) non login BASH
Segmentation fault
139
2) non login TCSH
Segmentation fault
139
3) login BASH
Segmentation fault
139
4) login TCSH
Segmentation fault
139


Additional info:

Comment 2 Suzanne Logcher 2012-02-14 23:18:21 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

Comment 3 Roman Rakus 2012-06-14 12:50:36 UTC
How is it related to bash?

Comment 4 Roman Rakus 2012-06-14 13:25:35 UTC
su isn't reporting that error message. Reassigning to coreutils.

Comment 5 Karel Volný 2012-06-14 15:47:49 UTC
(In reply to comment #3)
> How is it related to bash?

that the problem happens with bash and not with another shell ...

(In reply to comment #4)
> su isn't reporting that error message. Reassigning to coreutils.

... well, I thought that it is a matter of the shell to report the message, not that su should report it; IOW, I can get "Segmentation fault" message without involving su at all

however, I'm not an expert in these matters, feel free to prove me wrong; assigning to bash was just a first try

Comment 6 RHEL Program Management 2012-07-10 06:27:39 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 7 RHEL Program Management 2012-07-10 23:10:08 UTC
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 9 RHEL Program Management 2012-09-07 05:17:56 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 10 Ondrej Oprala 2013-04-29 13:31:59 UTC
Fixed in util-linux upstream a few months back: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/6438/focus=6445

Comment 13 Tomas Dolezal 2013-08-12 15:18:26 UTC
I suspect this patch bring new error as 128 is added to every exitcode above 0.

reproducer:
# getent passwd testuser >/dev/null || useradd testuser && for i in {0..3}; do su - testuser -c "exit $i"; echo $i:$?; done

actual:
0:0
1:129
2:130
3:131

expected:
0:0
1:1
2:2
3:3

could you please confirm this was brought by this patch and eventually fix it?

Comment 15 Ondrej Vasik 2013-08-13 13:54:39 UTC
I believe this is expected - Value 128+ is used to indicate failure to execute another program in a subprocess - exit 1/2/3 of subprocess (of exit 1/2/3 command) can be seen as failures. However, setting needinfo on Ondrej, so he can confirm that.

Comment 16 Tomas Dolezal 2013-08-13 17:21:22 UTC
just to be clear: this does not happen on currently released version.
Also on Fedora coreutils-8.21-11.fc19.x86_64 behaves normally without adding those 128.

Comment 17 Ondrej Vasik 2013-08-14 12:19:28 UTC
Ok, discussed with Ondrej via IRC, he already fixed the bug.

Comment 19 errata-xmlrpc 2013-11-21 20:54:41 UTC
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.

http://rhn.redhat.com/errata/RHSA-2013-1652.html