Bug 460778

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?

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'.

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

Didn't use Putty.  Was able to reproduce it using
Windows Telnet.  Can upload a 'core' file if that
will help.

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/

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

Created attachment 319279 [details]
RHEL5.2 'ksh' original binary and core from paste trap

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

(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.

Another thought:

Make sure you're not at the bottom of the screen when
performing the paste since scrolling can slow
things down greatly.

can you still reproduce this after 5.3 update?

Does this problem still appear with the rebased ksh that was added to RHEL5.3?

Haven't had a chance yet to apply the RHEL 5.3 update.
Will check it as soon as that's done.

(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

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.

> 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/

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.

>> 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.

(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

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.

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?

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.

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.