Bug 65786 - 'ftp client' doesn't ask for password in linux rescue mode
Summary: 'ftp client' doesn't ask for password in linux rescue mode
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ftp   
(Show other bugs)
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2002-05-31 17:51 UTC by David Tonhofer
Modified: 2007-04-18 16:42 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-13 09:18:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David Tonhofer 2002-05-31 17:51:33 UTC
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:)


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
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
write(4, "Password:", 9)  = 9  <-- this is not even displayed to the user
read(4, "", 4096)         = 0  <-- immediately returns

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 16:56:47 UTC
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 09:18:47 UTC
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.