Subject: DIR PROBLEM DEFINITIVE SOLUTION...

From: [email-masked]
Date: Fri, 19 Jan 1996 12:07:49 -0800

Cutting to the chase:
======================================================================
SOLUTION: 

    YOU NEED TO HAVE /ETC/GROUP!!!!!!  This is not optional. The ls 
command does not do the right thing if it does not have an 
/etc/group it can read.

======================================================================
ANALYSIS:

    So, here's my final analysis of the "dir/ls -l" problem.  I now 
understand the differences between /bin/ls and /usr/ucb/ls more than 
I care to, and also know more about the internal code of ftpd than I 
care to.  I also know why some sites have this problem right away, 
while others never experience it.

    I followed the FAQ, and ran truss on ~ftp/bin/ls.  Yes, all the 
libraries are in fact there.  I then ran 'chroot ~ftp /bin/ls', and 
that worked too.  That's not surprising, considering that tar and 
compress have always done the right thing.  While hacking about, I 
remembered/discovered that there is a /bin/ls and a /usr/ucb/ls on 
the system.  When I copied /usr/ucb/ls to ~ftp/bin/ls, everything 
appeared to work properly.

    I ran 'chroot ~ftp /bin/ls ' and 'chroot ~ftp /bin/ls.ucb'.  
Both of these worked.  So now the task was to find out why ftpd didn't 
like the /bin/ls.  After running multiple options through both 
versions of ls, the only real difference I could find was that the 
/bin/ls always showed group information, but /usr/ucb/ls did not.  I 
then tried 'chroot ~ftp /bin/ls -l' and 'chroot ~ftp /bin/ls.ucb -l'.  
Both of these core dumped.  Running truss with these binaries showed 
that they were both opening up the /etc/group file.

    When I copied /etc/group to ~ftp/etc/group, everything worked fine.

======================================================================
SO WHY DO SOME SITES HAVE THIS PROBLEM AND OTHER SITES DON'T?

    A) Some sites don't forget to copy /etc/group.  (BTW: This was 
buried in the Solaris ftpd man page.  Their discussion of the 
contents of directories lists each file needed by name on it's own 
line, while the section on /etc is pushed together into a single 
paragraph.  My fault for missing it because I didn't read the man 
page with a fine-tooth comb.)

    B) Some sites run a version of ls that does not show groups by 
default.  The test here is to do a 'ls -g' (show groups) and see if 
that works.  If it fails, then you don't have a ~ftp/etc/group file.

    C) Some sites (Non-Solaris-2.4) have a copy of ls that does the 
right thing when there is not a group file.  (ie, it shows that 
group number instead of core dumping.)

======================================================================
SUGGESTIONS FOR CHANGES:

   ftpd.c: This should really log an error message when something
           core dumps.

   ftpd/INSTALL: This mentions several problems with assorted 
           machines.  There should probably be a warning about
           this issue as well.

   ftpd/INSTALL: This mentions the mailing list.  It should
           reference the FAQ and any patch sites as well.

   FAQ: The FAQ should mention this problem/solution.  This really 
           is a "Frequently Asked Question", and this fix is much
           easier than trying to get the GNU fileutils package to
           compile and statically link.  (Yes, I know static is
           better, but some people will take that chance anyways.)

>>Ericw
(This was too much work, in my not so humble opinion.)

---

From: Michael Brennen <[email-masked]>
Date: Fri, 19 Jan 1996 14:50:41 -0600 (CST)

>     When I copied /etc/group to ~ftp/etc/group, everything worked fine.

Be careful doing this, especially with the ~ftp/etc/passwd file that has
to be present to give user IDs as well as group names.  Strip these files
to the bare minimum, REPLACE ALL ENCODED PASSWORDS WITH A *, give a bogus
shell, etc.  List no more users or groups than absolutely have to be there
to give an alpha name as owner and group.  Don't give away useful
information for cracking your machine.

I don't mean to be pedantic/picky in a nasty way, but it is important to
realize the impact of copying your unstripped /etc/passwd and /etc/group
files to guest or anonymous ~ftp/etc/{passwd,group} accounts.

I have the beta version running so that anything in the /etc directory
cannot be fetched, but probably not many are running this way.  This also
prevents real users from getting anything from the real /etc if you allow
real non-chrooted user ftp logins to your machine (use guest if you can). 
See the docs in the beta to find out how. 

Again, the beta location:

ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-8.tar.Z

You can't see the directory contents, but get the file anyway.  It's
there.

Michael
---------------------------------------------------------------------
Michael Brennen, President   /           /           [email-masked]
FishNet, Inc.               / Internet  /         http://www.fni.com/ 
P.O. Box 940451            /  Services /     (214) 783-2553 (vox/fax)
Plano,  TX  75094-0451    /           /  finger me for PGP public key

---

From: [email-masked]
Date: Mon, 22 Jan 1996 12:26:06 -0600 (CST)

I want to thank [email-masked] for the prompt reply, however
I'm still having difficulty.  I have a valid ~/ftp/etc/group.
I've downloaded, compiled, and statically linked the GNU ls
command and placed it into ~/ftp/bin (as well as ~/ftp/bin/ftp-exec
because I don't know what the hell that's for).

I gather that this is a common problem and that the above
are a couple of common solutions.  They don't seem to work
for me.  Any other ideas?

-- 
Disclaimer:  The above are my opinions and SSESCO can't have them!

William R. Nau
Supercomputer Systems Engineering and Services Company (SSESCO)
511 11th Avenue South, Suite 216
Minneapolis, Minnesota 55415-1536

Phone: 612-342-0003,  Email: [email-masked],  WWW: http://www.SSESCO.com