Subject: ls and DIR

From: Michael Will <[email-masked]>
Date: Tue, 15 Sep 1998 13:26:45 -0400

PS: If this post was seen before, please excuse the duplicate post.  I'm
not getting any confirmation that the post has succeeded or failed.

I am having problems setting up Version wu-2.4.2-academ[BETA-18] on a
Solaris 2.6 machine. Below are the steps that I completed:

1. Created a user account in the /etc/passwd file
"test:x:4000:4000:Testing FTP:/RAID/ftp-server/test/./:/etc/ftponly"

I have read that you needed a /etc/passwd file within the ftp server area,
however everything seems to be working.  The only problem that I'm having
is dealing with the ls and dir.

I noticed if you ftp to the UNIX ftp server from UNIX everything seems to
work fine.  The 'ls' command works.  If you do like wise from a DOS window
it works as well with 'ls' however, the "dir" fails.  Thus, my ftp clients
for Windows and Macintosh fail to see any files.

I have read the FAQ on the ls part and creating the /bin directories, but
confused as why everything seems to work fine, except that the ftp clients
seem to be using dir.

Any help is appreciated.

Michael

--
Michael Will                    |   Voice: (202) 767-9196 Ext. 226
Naval Research Lab Code 8140    |   Fax:   (202) 404-8918
4555 Overlook Ave. SW           |   E-mail: [email-masked]
Washington, DC 20375		|   Skypage: 1-800-SKY-PAGE #1528803

Key fingerprint =  B5BC B3BB 8995 D642 309F  9A12 9C4F D4A2 9774 DD13

---

From: Bob Luckin <[email-masked]>
Date: Tue, 15 Sep 98 12:54:35 CDT

Hi Michael,

> confused as why everything seems to work fine, except that the ftp clients

FTP has two commands to list directories, LIST and NLST.  If I remember
correctly, LIST asks for an "ls -l", while NLST asks for a simple list of
names.

Depending on the user command (ls, dir, ls -l, etc.) different FTP clients
behave differently when deciding whether to send the server NLST or LIST.

wu-ftpd uses built-in code (opendir, readdir etc.) when it thinks you want
the name list (NLST) (it tries to spot when some clients send NLST even though
the user typed "ls -l"), and calls the external /bin/ls when it thinks you want
the full directory list.

So if your external ls is not working correctly, you will find that (for some
clients) "ls" works because it uses the internal code, while "dir" and "ls -l"
don't work.

My guess is that this is your problem.  You say you have created the /bin
directory with a copy of "ls" under the chrooted area; have you made sure
that any dynamic libraries it needs are also present under the chrooted area ?

Cheers, Bob
-- 
Bob Luckin      [email-masked]      "I say ETA FTP ?  Me tempt fate, ya ?  Si !"
                                 [http://www.dhc.net/~luckin/palindromes/html]

---

From: "Scott Parmenter" <[email-masked]>
Date: Tue, 15 Sep 1998 13:05:31 -0700

> that any dynamic libraries it needs are also present under the chrooted area ?

I'm having difficulties similar to what Michael described.  Typing "ls" gives the
equivalent to "ls -a" but "ls -l" or "dir" gives:

150 Opening ASCII mode data connection for /bin/ls.
226 Transfer complete.

but gives no listing.  I've got a bin/ls in the chrooted area and libraries noted
by "ldd /bin/ls" have been copied to usr/lib in the chrooted area.  Are these the
libraries you referred to above?  I've verified the permissions on those files and
directories. When I do an ldd on the chrooted bin/ls, it still picks out the
original libraries in the "real" /usr/lib.  Is this causing a problem, or is that
detail transparent when the chroot is in effect?  I've tried to follow the in.ftpd
man page, but any help or suggestions would be greatly appreciated.

Scott

---

From: Bob Luckin <[email-masked]>
Date: Tue, 15 Sep 98 15:46:30 CDT

Scott said :-

> man page, but any help or suggestions would be greatly appreciated.

First off, yes, these are the libraries I was referring to.  What happens if
you execute chroot manually from your shell to execute /bin/ls ?  Does
it work then ?

If not, then you can also try to execute chroot from the shell and run
/bin/ls under truss, to see what it says in the trace you get.

Hopefully these will give you a better idea of whether your problem is due
to something missing from one of the directories under the chrooted area.

If it works OK when you are chrooted manually, then I'm out of ideas, but
perhaps someone else on the list will have some.

Good luck !

Cheers, Bob
-- 
Bob Luckin      [email-masked]      [http://www.dhc.net/~luckin/palindromes.html]
On mega data disks, attempt FTP. An inapt FTP; met task's ID a tad. A gem, no ?

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 15 Sep 1998 17:07:24 -0400 (EDT)

> > 150 Opening ASCII mode data connection for /bin/ls.

Problems of this type INVARIABLY come down to one or more of:

- missing programs (well duh)
- missing library files (if you're not statically linked)
- missing devices (if your system requires them)
- wrong permissions on the excutables, libraries, or devices
- symlinks don't work (so don't try 'em)

All of these issues are covered in the FAQ

The location of the latest version of wu-ftpd can be found in the 
directory
 
      ftp://ftp.academ.com/pub/wu-ftpd/private/
 
You can't see the directory contents, so read the message informing you
of the actual filename to retrieve. It's there.
 
wu-ftpd Resource Center:  http://www.landfield.com/wu-ftpd/
wu-ftpd FAQ:              http://www.cetis.hvu.nl/~koos/wu-ftpd-faq.html
wu-ftpd list archive:     http://www.landfield.com/wu-ftpd/mail-archive/

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: "Scott Parmenter" <[email-masked]>
Date: Tue, 15 Sep 1998 15:09:54 -0700

> you execute chroot manually from your shell to execute /bin/ls ?  Does

Ok, when I enter "chroot . /bin/ls" in what I want to be the chrooted root dir, I get
"ls: Cannot find /usr/lib/ld.so.1"  So, it looks like it doesn't know to look in the
chrooted usr/lib.  I've looked through the FAQ for this specifically, but I haven't
found how to change where chrooted bin/ls looks for its libraries.  Is this a common
problem that other folks have had to solve?   Is there a way to solve this without
building a statically linked ls, or is that the suggested solution?

Scott

---

From: Bob Luckin <[email-masked]>
Date: Tue, 15 Sep 98 17:41:28 CDT

Scott said :-

> building a statically linked ls, or is that the suggested solution?

That's one solution, but it shouldn't be necessary.  I haven't had to do
anything special to tell it where to look for the libraries, and it is
working fine on a Solaris 2.5 box for me.

However, I'm not using the guest user feature with the "/./" entries in
the password file - I'm only doing the chroot when someone logs in as
anonymous.  I can see that there _might_ be some difference in the ftpd code
between these two cases, but this wouldn't affect what happens when when you
are running under chroot from the shell, and you're seeing a problem there.

>From your description, it _is_ trying to look for /usr/lib/ld.so.1 in your
chrooted area, and can't find it for some reason.  My best guess is to
recheck the permissions on the <chroot_home>/usr and <chroot_home>/usr/lib
directories and make sure they are readable, and that files themselves also
have the correct permissions set.  If the problem isn't there, then I'm
running out of ideas...

Cheers, Bob
-- 
Bob Luckin      [email-masked]      "Dick's attempt FTP met task CID"
                                 [http://www.dhc.net/~luckin/palindromes.html]

---

From: "Scott Parmenter" <[email-masked]>
Date: Tue, 15 Sep 1998 15:59:10 -0700

Bob Luckin wrote:

> chrooted area, and can't find it for some reason.

Ok, I found the problem.  Turns out I'm a dufus. :-)  I forgot to add the loader to
usr/lib.  That _is_ what ld.so.1 is, right?  I had just blindly copied the libraries
indicated by ldd.  Anyway, I added it, and now ls -l works.

Thank you for bearing with me.  I know I wouldn't have solved this so quickly without you
and Gregory helping me.

Scott