Bug 170160 - Sudo display password entry when AT&T ksh is login shell
Sudo display password entry when AT&T ksh is login shell
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sudo (Show other bugs)
3.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Vrabec
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-07 16:08 EDT by Cindy Marasco
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 14:53:33 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)
testcase with tgetpass() from RHEL3 sudo (7.34 KB, text/plain)
2005-10-12 07:22 EDT, Karel Zak
no flags Details
strace of tgetpass (3.33 KB, text/plain)
2005-10-12 11:18 EDT, Cindy Marasco
no flags Details

  None (edit)
Description Cindy Marasco 2005-10-07 16:08:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051004 Firefox/1.0.7 (Ubuntu package 1.0.7)

Description of problem:
When users with ksh as their login shell use sudo their password entry is displayed on the screen instead of being blanked out like it normally is.

Behavior does not occur with ksh as a non-login shell, but is seen with either their shell in /etc/passwd is ksh or if they invoke ksh with 'ksh -l'.  i386 boxes with the same version of ksh don't seem to have this problem.



Version-Release number of selected component (if applicable):
ksh-20050202-0.3E.1

How reproducible:
Always

Steps to Reproduce:
1. ksh -l
2. sudo ls /root
3. Type things in the password prompt
  

Actual Results:  You see the characters you typed on the screen

Expected Results:  Characters should have been blanked out to protect password

Additional info:
Comment 3 Karsten Hopp 2005-10-11 08:26:11 EDT
I've installed RHEL-3_x86_64 U6 on my system and cannot reproduce this problem.
Did you encounter this on the console or while using KDE/Gnome ?
Which terminal and which language settings did you use ?
- echo $TERM
- ps
- echo $LANG
Comment 5 Cindy Marasco 2005-10-11 12:35:33 EDT
I see this behavior from the console or when I ssh in (I've seen it with both
Linux openssh clients and Windows FSecure and putty).  The box is a server so I
don't have X installed on it.

From my linux client:
-----------------------------
$ echo $TERM
xterm
$ ps
  PID TTY          TIME CMD
21856 pts/5    00:00:00 ksh
21877 pts/5    00:00:00 ps
$ echo $LANG
en_US.UTF-8
$ sudo bash
Password:sdfasfdasd

---------------------------------

The output is basically the same from the other locations, except the $TERM is
linux from the console and vt100 from the Windows SSH clients.
Comment 6 Karsten Hopp 2005-10-12 04:31:41 EDT
I still cannot reproduce this with the same TERM and LANG settings. Any ideas from
the sudo maintainer ? I always thought that sudo would disable echoing the
password input  altogether and not just make it 'invisible', so I'm not sure
what is happening here.
Comment 7 Karel Zak 2005-10-12 07:22:18 EDT
Created attachment 119830 [details]
testcase with tgetpass() from RHEL3 sudo 

Please, try this attachment on your system.

  $ gcc -g -O2 -Wall -o tgetpass tgetpass.c
  $ ./tgetpass
  Type any text:
  your text: "qwer"

Note that it's same code as the sudo uses for password reading. Please, I would
like to see "strace ./tgetpass", if you're able reproduce the "echoing" problem
with this test. Thanks.
Comment 8 Cindy Marasco 2005-10-12 11:18:41 EDT
Created attachment 119839 [details]
strace of tgetpass
Comment 10 RHEL Product and Program Management 2007-10-19 14:53:33 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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