Bug 460778 - 'ksh' traps on text paste into 'cat >outfile'
'ksh' traps on text paste into 'cat >outfile'
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: ksh (Show other bugs)
5.2
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Michal Hlavinka
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-31 15:02 EDT by starlight
Modified: 2009-04-11 20:34 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-06 05:23:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
RHEL5.2 'ksh' original binary and core from paste trap (606.19 KB, application/octet-stream)
2008-10-02 14:53 EDT, starlight
no flags Details

  None (edit)
Description starlight 2008-08-31 15:02:58 EDT
Description of problem:

'ksh' traps on text paste into 'cat >outfile'

Version-Release number of selected component (if applicable):

ksh-20060214-1.7

How reproducible:

Issue 'cat >outfile' and then paste in some text.
  
Actual results:

per 'dmesg'

ksh[2783]: segfault at 0000000000000000 rip 000000000040650d rsp 00007fffc2241ac8 error 6

Expected results:

should create text file after paste and CTRL-D is typed

Additional info:

Using 'tn2000' if that matters, though probably not
as it happens even if 'ssh' is used via an intermediate
different system.

Worked around this by replacing RHEL5 'ksh' with RHEL4 'ksh'.
Comment 1 Michal Nowak 2008-09-01 05:11:08 EDT
If I understand it right, this should be the reproducer?

.live.[root@x86-64-5s-m1 ~]# rpmquery ksh
ksh-20060214-1.7.x86_64

.live.[root@x86-64-5s-m1 ~]# cat >outputfile
sdsd
sdsd

.live.[root@x86-64-5s-m1 ~]# cat outputfile
sdsd
sdsd



As you can see this runs OK for me? Can you comment on this?

Isn't it somehow related to your setup? Does it happen on all systems?
Comment 2 starlight 2008-09-01 13:26:18 EDT
Try using a lot more text.  At least 500-1000 characters.

Next make sure it's a '/dev/pts/x' via either 'ssh' or 'telnet'.
Run that from a MS windows desktop.

Perhaps it matters that the 'ksh' is the top-level
shell specified in '/etc/passwd'.
Comment 3 Michal Hlavinka 2008-10-01 04:07:10 EDT
I can't still reproduce this bug...

Computer with RHEL 5.2:
# useradd kshtest -s /bin/ksh
# passwd kshtest

windows computer with putty:
# rpm -q ksh
ksh-20060214-1.7
# tty
/dev/pts/2
# cat >outfile
<past text from firefox - putty download page - select all>
<ctrl+d>
# ls
outfile


I pasted:
whole download page
only 736 characters
only 736 characters + non ascii characters

and it always works
Comment 4 starlight 2008-10-01 12:06:06 EDT
Didn't use Putty.  Was able to reproduce it using
Windows Telnet.  Can upload a 'core' file if that
will help.
Comment 5 Michal Hlavinka 2008-10-02 06:43:08 EDT
Still no success (failure)...

RHEL 5.2:
1)install and enable telnet
2)useradd kshtest -s /bin/ksh

win:
1)telnet
2)o testmachine
3)login as kshtest user
4)cat >outfile
a)whole download page
b)only 736 characters
c)only 736 characters + non ascii characters

still works for me, so...

Please upload that core file, if you have it, but the possibility to reproduce this bug is much more valuable for me, so...

Can you reproduce this bug always or only sometime? How often is it?
Can you reproduce it with pasting any text always? If not, can you attach file containing text which can reproduce it?
Can you provide as much detailed howto as possible? All (even obvious) steps with as much concrete values as you can? 

KSH will be rebased in RHEL 5.3, so if you want, you can try to reproduce this bug with unofficial ksh packages : http://mhlavink.fedorapeople.org/ksh/
Comment 6 starlight 2008-10-02 14:49:19 EDT
Core was generated by `/bin/ksh.orig'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000040650d in readdir64 ()
(gdb) where
#0  0x000000000040650d in readdir64 ()
#1  0x00000000004362e3 in putenv ()
#2  0x0000000000438b8d in putenv ()
#3  0x00000000004392f2 in putenv ()
#4  0x0000000000410fbd in readdir64 ()
#5  0x000000000048973c in regfree ()
#6  0x0000000000487270 in regfree ()
#7  0x00000000004a7ed4 in remove ()
#8  0x00000000004311fc in putenv ()
#9  0x0000000000405c6b in readdir64 ()
#10 0x000000000040519a in readdir64 ()
#11 0x00002acd587308b4 in __libc_start_main () from /lib64/libc.so.6
#12 0x0000000000404439 in readdir64 ()
#13 0x00007fff52a37698 in ?? ()
#14 0x0000000000000000 in ?? ()

(gdb) i reg
rax            0x44     68
rbx            0x17     23
rcx            0x0      0
rdx            0x17     23
rsi            0x1291f0f0       311554288
rdi            0x0      0
rbp            0x129299c0       0x129299c0
rsp            0x7fff52a33358   0x7fff52a33358
r8             0x0      0
r9             0x0      0
r10            0x15     21
r11            0x246    582
r12            0x129299c0       311597504
r13            0xfffffff6       4294967286
r14            0x4390f0 4428016
r15            0x0      0
rip            0x40650d 0x40650d <readdir64+8549>
eflags         0x10206  [ PF IF RF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
Comment 7 starlight 2008-10-02 14:53:30 EDT
Created attachment 319279 [details]
RHEL5.2 'ksh' original binary and core from paste trap
Comment 8 Michal Hlavinka 2008-10-08 03:23:01 EDT
With core dump I can see why it caused the sigsegv but still can't see what went wrong. Can you answer my questions from comment #5? thanks
Comment 9 starlight 2008-10-08 12:12:23 EDT
(In reply to comment #5)
> Can you reproduce this bug always or only sometime? How often is it?

Always, every time, 100%.

> Can you reproduce it with pasting any text always?

Yes.

>If not, can you attach file containing text which can reproduce it?

The core file I sent was produced by pasting the "description"
section above.

> Can you provide as much detailed howto as possible?
>All (even obvious) steps with as much concrete values as you can? 

Try this:

Start from a Windows system with CYGWIN installed.
1) start a CMD window
2) issue c:\cygwin\bin\ssh <target>
3) issue '/bin/ksh.orig' # maybe you don't need this
4) issue 'ulimit -c unlimited'
5) issue 'cat >outfile'
6) paste 100 or 200 characters of any text, such
as these instructions.
7) BOOM

This reproduces the problem 100% of the time for me.
Also works from a master console on a Linux box.
So my Telnet 3270 and Telnet 2000 clients are
not essential.

> 
> KSH will be rebased in RHEL 5.3, so if you want, you can try to reproduce this
> bug with unofficial ksh packages : http://mhlavink.fedorapeople.org/ksh/

I'll try to get to this in the next day or two.
Comment 10 starlight 2008-10-08 12:14:32 EDT
Another thought:

Make sure you're not at the bottom of the screen when
performing the paste since scrolling can slow
things down greatly.
Comment 11 Michal Hlavinka 2009-01-26 10:59:12 EST
can you still reproduce this after 5.3 update?
Comment 14 Denise Dumas 2009-03-13 14:59:24 EDT
Does this problem still appear with the rebased ksh that was added to RHEL5.3?
Comment 15 starlight 2009-03-13 15:12:47 EDT
Haven't had a chance yet to apply the RHEL 5.3 update.
Will check it as soon as that's done.
Comment 17 Michal Hlavinka 2009-03-18 08:36:13 EDT
(In reply to comment #15)
> Haven't had a chance yet to apply the RHEL 5.3 update.
> Will check it as soon as that's done.  

ok, please tell us the result once you test it

thanks
Comment 18 starlight 2009-04-05 18:34:14 EDT
Retried it with RHEL 5.3 and the problem seems to have been fixed.

However I'm sticking with RHEL 4.x 'ksh' anyway as the
new version of 'ksh' fails to set PS1='# ' after
a SUID root.  Looks to me like 'ksh' is not really being
maintained so older is better.
Comment 19 Michal Hlavinka 2009-04-06 05:20:49 EDT
> new version of 'ksh' fails to set PS1='# ' after a SUID root.

what way are you trying to set PS1 ?

> However I'm sticking with RHEL 4.x 'ksh' ...
> ... Looks to me like 'ksh' is not really being
> maintained so older is better.

FYI, older ksh in RHEL-4.x is in fact pdksh with no upstream development for last ten years

ksh in RHEL-5.x has still active upstream at http://www.research.att.com/sw/download/
Comment 20 Michal Hlavinka 2009-04-06 05:23:07 EDT
Because of "Retried it with RHEL 5.3 and the problem seems to have been fixed." from comment 18, I assume new version of ksh in rhel-5.3 fixes this problem.
Comment 21 starlight 2009-04-06 10:58:20 EDT
>> new version of 'ksh' fails to set PS1='# ' after a SUID root.
>
>what way are you trying to set PS1 ?

Said it wrong.  Just performing a simple 'su' is what
I meant.  Drives me crazy to not see when I'm
running a root shell.  For awhile I kept setting
PS1 manually after 'su', but that's truly a pain.
Loaded up the old 'ksh' and it works like a charm.

>> However I'm sticking with RHEL 4.x 'ksh' ...
>> ... Looks to me like 'ksh' is not really being
>> maintained so older is better.
>
>FYI, older ksh in RHEL-4.x is in fact pdksh with no upstream development for
>last ten years
>
>ksh in RHEL-5.x has still active upstream at
>http://www.research.att.com/sw/download/

Well older is truly better then.  Actually the main reason
I use 'ksh' is I dislike the editor key binding in 'bash'
and haven't taken the time yet to create a 'readline'
configuration to set key preferences I'm used to.

Annoying that 'ash' was dropped from RHEL5 as well.
It's super-lightweight and useful at times--maintained
or not maintained.  So I install the old RPM for that.
Comment 22 Michal Hlavinka 2009-04-09 05:25:09 EDT
(In reply to comment #21)
> >> new version of 'ksh' fails to set PS1='# ' after a SUID root.
> >
> >what way are you trying to set PS1 ?
> 
> Said it wrong.  Just performing a simple 'su' is what
> I meant.  Drives me crazy to not see when I'm
> running a root shell.  For awhile I kept setting
> PS1 manually after 'su', but that's truly a pain.
> Loaded up the old 'ksh' and it works like a charm.

I have /bin/bash as default shell, so I've tested it with
su --shell=/bin/ksh
and
su - --shell=/bin/ksh

and both worked for me.

Then I've changed default shell for root in /etc/passwd 
and using 'su' and 'su -' also works for me.

Tested in rhel-5.3 using ksh-20080202-2.el5
Comment 23 starlight 2009-04-09 09:42:50 EDT
The indicated test works the same here.

Problem appears when 'ksh' is the default
shell for an account.  Then the # prompt
does not appear after a plain, parameterless
'su' command.
Comment 24 Michal Hlavinka 2009-04-09 10:31:11 EDT
I've created user kshuser, set default shell to ksh in /etc/passwd and set default shell to ksh for root. For kshuser I get '$' prompt and after 'su' it changes to '#'.

tested in rhel-5.3

what way do you use it?
Comment 25 starlight 2009-04-09 11:02:20 EDT
Figured out the problem results from setting

   PS1='$ '
   EXPORT PS1

in .profile.


If an exported PS1 variable is present, 'su'
keeps that value instead of establishing a #

Also determined that SHELL=/bin/ksh is all that's
needed.  Doesn't have to be the account shell.
Comment 26 starlight 2009-04-11 20:34:25 EDT
Just noticed I overlooked my 'su' script (forgot I had
it; has a 2002 creation date):

/bin/su -m ${@}

So I have the -m (retain enviorment switch on the 'su' line.
This usually keeps almost all of the environment, but
replaces the value of PS1 with '# ' regardless.  The new
'ksh' version seems to just keep everything the same.

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