directory not visible in ftp session

[prasadb]

hello all ..

i have HP-UX superdome server. the version B.11.11. i have one strange problem.

there are some users on the users to whom /usr/bin/false shell has been alloted, so that they can have only FTP session but not the telnet.

well, now the problem is that once the user login into the FTP session, and fire pwd command they see this message.

"257 "/" is current directory.". whereas, the home directory is set properly. i have checked it in passwd file.

And when he hits "ls" command , files are not visible in the session. check the session as below..

Also, i changed the shell to /usr/bin/sh, the normal shell by default, but the problem still exists.

Following is the message the user getting.

# ftp 10.4.5.62

Name (10.4.5.62:root): gujtap
331 Password required for gujtap.
Password:
230 User gujtap logged in. Access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
227 Entering Passive Mode (10,4,5,62,192,74)
150 Opening ASCII mode data connection for /usr/bin/ls.
226 Transfer complete.
ftp> pwd
257 "/" is current directory.
ftp>


NOTE:this problem exists for some particular users, not all.

Help !!!!

[prasadb]

i forgot to metion that , when i do the same from the command prompt, it works fine, the problem is only when the the user is doing it from another server.

[prasadb]

Till nobody there ? :-)

i have posted one more question on Linux Admin group, plz see that too :-)

[Dennis Handly]

Is this user's ftp chrooted?
Can you do "ls -i" to get the inode then use
find(1) to find what directory is /?

[prasadb]

# cat /etc/passwd | grep gujtap
gujtap:HqwLe1vYyxNB6,5.oT:136:20:,,,:/uu08/gujtap:/bin/false
#
# cd /uu08/gujtap
# ls -i
2994 .cshrc 2997 .profile 4338 CDINDMPINDBI03248
2995 .exrc 3002 .sh_history 2998 ideabill
2996 .login 4330 CDINDMPINDBI03247 4340 test


NOTE:gujtap is the user who has the problem.

Best Regards,
prasad

[john korterman]

Hi prasabd,

without knowing the details about your system, I think the above is a description of how a secure ftp session is actually supposed to work: when the user logs on in a restricted ftp session he is not supposed to se anything above his starting point, which is why the system displays "/" as his home dir.
When the user executes ls, nothing happens because he has not access to the normal /usr/bin/ls. You can remedy that by making the /usr/bin directory structure under the user's home dir and then copy the root user's ls command ie. /sbin/ls to the user's /usr/bin/ls
which should work. member execute permission!

regards,
John K.

[Dennis Handly]

# cd /uu08/gujtap
# ls -i

Oops that should have been "ls -dli" in ftp.
You obviously know it isn't the same directory as /uu08/gujtap.

[prasadb]

>when the user logs on in a restricted ftp session he is not supposed to se anything

exactly. but what about the files that come under his home directory ? and as expained when he does it from the command prompt, he is able to see the files, but when he does it from the another server he is able to do so.

Let say, my server is X and he opens FTp session from Y or any other sever then he can login into that but not able to "see" any file.

[prasadb]

Dear Dennis,


# cd /uu08/gujtap
# ls -dli
2993 drwxr-xr-x 3 gujtap users 8192 Jan 12 13:31 .
#
# ls
.cshrc .login .sh_history CDINDMPINDBI03248 test
.exrc .profile CDINDMPINDBI03247 ideabill

[Dennis Handly]

># ls -dli

Now you need to do this command IN ftp. That will tell you what directory you are actually using.

[prasadb]

Here is the o/p

ftp> ls -dli
200 PORT command successful.
150 Opening ASCII mode data connection for /usr/bin/ls.
226 Transfer complete.

[Dennis Handly]

>Here is the o/p

Rats, it doesn't look like it wants to honor those ls(1) options. I don't think quoting them will help?

[prasadb]

Hmmnn..

any other option plz ?

[Steven Schweda]

> Is this user's ftp chrooted?

Well, is it?

If so, FTP LIST ("ls") commands may fail
because the ftp server process can't find an
"ls" program to run (and/or any run-time
libraries which it might need).

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1206014
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=800673
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=7702
[...]

(Forum search for: "ftp ls chroot /sbin/ls")

[Steven Schweda]

> Rats, [...]

Better to turn on debugging in the FTP client
program, so that you have some idea what's
actually being sent to the FTP server (than
to curse the darkness).

But if the FTP server is trying to run "ls"
(with or without any particular options), and
it can't find a working "ls", then it won't
matter much what ornate stuff the client
sends.

[Dennis Handly]

>any other option plz?

This is what I expected:
ftp> ls -id
227 Entering Passive Mode
150 Opening ASCII mode data connection for /usr/bin/ls.
16 dr-xr-xr-x 5 root other 96 Jul 22 11:25 .

[prasadb]

hello all,

Thank you very much for your continuous support and interest taken in order to resolve my problem.

well, i have done some changes in /etc/inetd.conf file as below


#ftp stream tcp nowait root /usr/lbin/ftpd ftpd -l

previously it was ..

#ftp stream tcp nowait root /usr/lbin/ftpd ftpd -l -a -d

i removed the "-a" option, and the user is able to view the o/p of "pwd" as well as the "ls" commands.

Though, the problem seems to be solved, the user has got the ablity to delete the files ( under his home directory), which was not the case earlier.

i don't understand the reason behind it, but am sure that you all experts might be knowing the exact cause behind all this.

would anybody like to throw some light on this issue ?

Thank you,
prasad

[Dennis Handly]

The -a option enables /etc/ftpd/ftpaccess.
What did you have in that file?

[prasadb]

Dear Dennis,

plz have a look at the /etc/ftpd/ftpaccess file. i have attached here.

Best Regards,
prasad

[Dennis Handly]

>plz have a look at the /etc/ftpd/ftpaccess file.

You have a line that looks strange. Did it get chopped when you pasted it?
renamenoguest,anonymous# rename permission?

[Elmar P. Kolkman]

Since logging is enabled, what does the ftpdaemon report in the syslog.log file when the restriction is enabled ?
And what is in the ftpusers file ?

[Steven Schweda]

> NOTE:this problem exists for some
> particular users, not all.

[...]
> # specify which group of users will be treated as "guests".
[...]
> guestgroup ftpusers
[...]

So, are any of these problem users in the
"ftpusers" group? (Do you have an "ftpusers"
group?)

> > Is this user's ftp chrooted?
>
> Well, is it?

_Still_ waiting for an answer to that one.

A guest user would get the chroot(), which
could explain the "257 "/" is current
directory." message. And, if you didn't read
"man ftpd" (or equivalent), and so you didn't
follow the directions for setting up these
users' home directories ("[...] exactly as
anonymous FTP would be [...]"), then that
could also explain the "ls" problem.

> would anybody like to throw some light on
> this issue ?

You first.

Even if "ls" does not work, you could put a
file into a user's home directory, and then
try to fetch it by name using FTP. (You
don't need a working "ls" if you already know
the file name.) If that works, then you'll
know that you're in the right directory, and
if the FTP server was calling it "/", then
you'll know that it has done a chroot(). And
if that's true, then "man ftpd" and "man
ftpaccess" should provide all you need to
know. (At least about this problem.)

Another possible clue, using the HP-UX FTP
client: The FTP client "ls" command sends a
"LIST" command to the FTP server, and that
needs a working "ls" program. The "nlist"
command sends an "NLST" command to the FTP
server, and that does _not_ need a working
"ls" program. For example, without a good
"ls" (because I renamed "usr" to "usr_"):

ftp> debug
Debugging on (debug=1).
ftp> ls
---> PORT 10,0,0,39,193,134
200 PORT command successful.
---> TYPE A
200 Type set to A.
---> LIST
150 Opening ASCII mode data connection for /usr/bin/ls.
226 Transfer complete.
[Note the lack of useful output there.]
---> TYPE I
200 Type set to I.
ftp> nlist
---> PORT 10,0,0,39,193,135
200 PORT command successful.
---> TYPE A
200 Type set to A.
---> NLST
150 Opening ASCII mode data connection for file list.
etc
dist
upload
usr_
[Note the non-empty file list.]
226 Transfer complete.
---> TYPE I
200 Type set to I.
ftp> pwd
---> PWD
257 "/" is current directory.
ftp>

Again, with a good "ls" ("usr" is "usr"
again):

ftp> ls
---> PORT 10,0,0,39,193,150
200 PORT command successful.
---> TYPE A
200 Type set to A.
---> LIST
150 Opening ASCII mode data connection for /usr/bin/ls.
total 0
dr-xr-xr-x 2 root other 96 Jan 7 2008 dist
dr-xr-xr-x 2 root other 96 Jan 7 2008 etc
drwxr-xr-x 2 ftp daemon 96 Nov 21 21:58 upload
dr-xr-xr-x 4 root other 96 Jan 7 2008 usr
226 Transfer complete.
---> TYPE I
200 Type set to I.
ftp>

As the message says, the FTP server is
looking for "/usr/bin/ls". If it can't find
one, then it can't provide a LIST report.

[prasadb]

>You have a line that looks strange. Did it get chopped when you pasted it?
Dennis, the file is a session log from putty, it is as it is on the machine, no manupulations done.
>what does the ftpdaemon report in the syslog.log file when the restriction is enabled ?
Nothing about this issue.
>Is this user's ftp chrooted?
no chroot used for any command for any user.
>specify which group of users will be treated as "guests" ?
?
> Do you have an "ftpusers" group?)
yes, i have.

plz see the line from /etc/group..

ftpusers::106:delhitap,gujtap,hptap

and these users had above explained problem.

waiting for your valuable inputs/comments..

[Steven Schweda]

> no chroot used for any command for any user.

"man ftpd". Look for "chroot". _You_ are
not using chroot(), but the FTP server is.

> and these users had above explained problem.

Amazing.

> waiting for your valuable inputs/comments..

You already have them. All "5 pts" worth.
Do you want me to type it all again? You
might try reading "man ftpd". Have I
suggested reading "man ftpd"? I believe that
it's all explained in the ftpd "man" page.
If that fails, try also "man ftpaccess".
Then go back and read "man ftpd" again.

[Dennis Handly]

>the file is a session log from putty, it is as it is on the machine, no manipulations done.

Then you need to fix that line. (Unless that line was split when attached?)

If that doesn't fix it, you may have to comment out lines in ftpaccess until you find what causes it to fail.