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.
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.
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.
it would be nice if you always got a second chance
>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.
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).
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.
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 .
> 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.
>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.
"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.
