Bug 65786 - 'ftp client' doesn't ask for password in linux rescue mode
'ftp client' doesn't ask for password in linux rescue mode
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: ftp (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-31 13:51 EDT by David Tonhofer
Modified: 2007-04-18 12:42 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-13 05:18:47 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)

  None (edit)
Description David Tonhofer 2002-05-31 13:51:33 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
'ftp client' behaves wierdly in rescue mode: when connecting to a
remote machine, it correctly sends the username but then does not
ask for the password (i.e. the 'Password:' prompt never shows up) but
immediatly sends an empty password to the remote server (I checked the
logs on the server side) upon which the login fails, as expected, because the 
password does not match. 

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


How reproducible:
Couldn't Reproduce

Steps to Reproduce:
1. Boot linux in rescue mode
2. Set up net connections
3. Try to ftp to a remote machine
	

Actual Results:  Empty password is sent and thus login fails

Expected Results:  ftp client should ask for password

Additional info:

Looking around on the net, I found an old thread mentioning said 
problem on AIX (and here is the URL:)

http://groups.google.com/groups?
hl=en&lr=&ie=UTF8&oe=UTF8&safe=off&th=86c3c627447ad9b8&rnum=1

In that thread, it turned out that permissions on /dev/tty* were not
set correctly.

We possibly have a similar problem here. Possible leads:

- ftp opens up "/var/run/utmp" but this fails because there is no such
  thing in rescue mode. Does this affect anything?
- for the password, it tries to read stuff from file descriptor 4 
  which is /dev/tty, but the read() call returns immediately.

Here is the strace from ftp under redhat 7.0, non-rescue mode. This 
describes a correct, working login:

open("/dev/tty",O_RDWR|O_CREAT|O_TRUNC,0666) = 4
ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(4, SNDCTL_TMR_CONTINUE, {B38400 opost -isig icanon -echo ...}) = 0
fstat64(4, {st_mode=S_IFCHR|0666, st_rdev=makedev(5, 0), ...}) = 0
ioctl(4, TCGETS, {B38400 opost -isig icanon -echo ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x4001b000
write(4, "Password:", 9)                = 9
read(4, "areyouserious\n", 4096)        = 11
write(4, "\n", 1)                       = 1
ioctl(4, SNDCTL_TMR_CONTINUE, {B38400 opost isig icanon echo ...}) = 0
close(4)                                = 0

Here is the strace from ftp under redhat 7.3, rescue mode. This does
not work:

open("/dev/tty",O_RDWR|O_CREAT|O_TRUNC,0666) = 4
ioctl(4,SNDCTL_TMR_TIMEBASE,0xbfffeb00) = -1 ENOTTY
fstat64(4, {st_mode=S_IFREG|0777,st_size=0, ....})=0
old_mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 
0x401c1000
write(4, "Password:", 9)  = 9  <-- this is not even displayed to the user
read(4, "", 4096)         = 0  <-- immediately returns
close(4)

The **workaround** is to create a .netrc with machine, login and
password information. ftp will then try auto-login using that
information and will not ask the user.
Comment 1 Lee Sheridan 2003-11-12 11:56:47 EST
This still seems to exist in Advanced Server 2.1 and RH 8.0 - It would
have saved me a great deal of time to have this fixed.  So just a note
that this bug has hit multiple people.
Comment 2 Thomas Woerner 2004-08-13 05:18:47 EDT
Please verify this with a newer version of Red Hat Enterprise Linux or Fedora
Core and reopen it against the new version if it still occurs.

Closing as "not a bug" for now.

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