FTP Credential Issue via IE8?

[Ed Budurka]

I'm new to HP-UX, dilemna is: ftp from windows into hp-ux box with "normal" user, get dropped into /home/user. Same user uses IE8 and does FTP://hpuxbox, authenticates with "normal" userid and gets a directory listing of root's files. If you click on "Page" and "Open FTP Site in Windows Explore" you have to authenticate again (with normal user) and you then get dropped into the "normal users account. I have looked/researched and cannot come to any conclusion as to why this occurs. Any ideas or pointers? /etc/inetd.conf ftp settings are: ftp stream tcp6 nowait root /usr/lbin/ftpd ftpd -l

[Torsten.]

IMHO this is a pure IE8 problem, I solved this by using filezilla as a client.

[Michal Kapalka (mikap)]

hi,

you could use :

ftp://ftpuser@hpuxbox

ftp://ftpuser:ftppassword@hpuxbox


mikap

[Ed Budurka]

Thanks Torsten and Michal. I've tried Michal's approach with the same result. I've also tested using filezilla, and ws-ftp, both successful/no problems. I still though have this IE problem and have no way to control an IE user within our network with a valid HP-UX id with FTP capability from signing on via IE and getting to that root directory listing. I guess my final question would be to Torsten, in your experiences have you been able to "disable" all attempts to use FTP via IE?

[Steven Schweda · Accepted solution]

> [...] have you been able to "disable" all
> attempts to use FTP via IE?

FTP servers are generally designed to handle
requests, not to interrogate the client. A
client may care which FTP server it's using,
but I've never seen a server who cares about
the client.

If you need to be selective among different
client programs, then you might do better by
disabling FTP access, and switching to HTTP.
Web servers generally have lots of options in
this neighborhood.

Alternatively, you might look at setting up
FTP "guest" accounts on the HP-UX system.
With the chroot() action this implies, you
should be able to avoid exposing any files
outside the guest users' local file tree(s).
("man ftpd", look for "guest".)

You could probably enable some more detailed
diagnostics on the FTP server to see exactly
what MSIE is doing, but, while potentially
interesting, that might not get you any
closer to solving the problem. My guess is
that it's sending a "CWD /" (for no good
reason), which would do less damage in a
guest/chroot() environment.

> [...] gets a directory listing of root's
> files. [...]

Good reason to check the permissions there,
if one were needed.


> IMHO this is a pure IE8 problem [...]

I've grown to expect MSIE not to work with my
VMS (TCPIP) FTP server, but this is the first
I've heard of it getting confused by a
UNIX(-like) FTP server. Remarkable.

[Torsten.]

I previously installed IE8 on my PC and I have seen strange problems with FTP downloads. I did some google research regarding IE8 and FTP and found many similar complains. Finally I went back to IE7 and everything is working again.

[Ed Budurka]

Everyone, thank you for the assistance. The last update from Steven, and the fact I wasn't giving up, provided a workable solution to the problem. I simply turned on -L logging to syslog.log in the inetd.conf file. Saw that IE was attempting to do things "anonymously". Then defined an anonymous userid (ftp); defined all the specific directories; copied the specified files and recycled the daemon per document http://docs.hp.com/en/B2355-60130/ftpd.1M.html The one thing I did differently from the doc was chroot'd to a directory with "nothing" in it. My contention is the folks using FTP via IE should'nt be and should be using a client such as filezilla, ws-ftp etal. Also my testing showed no effect on the operation of those clients. Thanks again, look forward to your comments in the future.

[Ed Budurka]

see previous updates comments

[Steven Schweda]

> [...] The one thing I did differently from
> the doc was chroot'd to a directory with
> "nothing" in it. [...]

It might be helpful to leave some kind of
README file there, containing suggestions to
help the victim find the true path to
enlightenment. (Might save some annoying
phone calls from the bewildered.)

Another nice thing about a typical HTTP
server is its ability to serve a file (like a
README) which has nothing obvious to do with
the original request. (Sometimes it's nice.)