Subject: Solutions for wu-ftpd on Solaris

From: [email-masked]
Date: Fri, 29 May 1998 16:10:54 -0100 (GMT)

Good morning/afternoon/night(??)! I'm writing this mail hoping that
it can help someone with the same problem, and because it can exist a better
solution in this case.

  I run wuftp on Solaris 2.5.1, and I've had to setup wuftpd in order to log
in 'guest mode' (i.e. chroot-ing every guest user that logs into the
machine). The main problem was that we have ~1200 'guest users' (the box
also works as web server, and they need to put by ftp their pages under
~user/public_html/). And all needed a complete structure (bin/, etc/,
usr/bin/, usr/lib/, dev/, etc/) and ls & dynamic libraries also. The
libraries spend ~1.8 MB. And now!...1.8 MB*1200 users...=MANY DISK SPACE!
Solution?

  One solution (I don't know if the better solution) is to compile a 'static
ls', and copy this special ls to every bin/ directory.

  The other (the one I choose) is to hardlink, using 'ln src-file dst-file',
all the files needed. All users then share one real copy of ls, one copy of
ld.so, ld.so.1, libc.so.1 and so on. (For all the guys that are saying: This
can be a security breach, because you're sharing the system ls!... I say you
no, the ls used in this experiment is a copy (a copy, not a link) of the
system ls.)

        Am I right? Am I an idiot?

        David.
--
Systems Mantainer
Aulas de Informática
Universidad Autónoma de Madrid
Spain

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 29 May 1998 11:53:38 -0400 (EDT)

>         Am I right? Am I an idiot?

Given your environment, you're right.

here, my users are all on a single directory heirarchy (/home/users), each
is in a private group, and permissions are forced to deny world or group
write anywhere in /home/users .. so I can chroot to the common point and
only need one copy of the bin/ and etc/ directories.

Using a copy of the ls (et al) is a very good idea, hardlinking is fine if
you can do it.  I keep four copies myself (actually five, I have a
secured version for intrusion detection): system, chroot'd user, anonymous
ftp, guestgroup/dropbox (almost anonymous) chroot'd users.

----

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

---

From: Emil Isberg <[email-masked]>
Date: Sat, 30 May 1998 02:21:52 +0200 (MET DST)

>libraries spend ~1.8 MB. And now!...1.8 MB*1200 users...=MANY DISK SPACE!

You could make static binaries, yes .. and you could also:
* Put the followint rows at the end of /etc/vfstab
/guestlib - /path/to/guest/home/lib lofs - yes ro
/guestdev - /path/to/guest/home/dev lofs - yes ro
 ^       ^^         ^                ^   ^  ^  ^
(1)  (2)-||-(3)    (4)              (5) (6)(7)(8)

(1) The path to correctly set up directories that work in a chrooted
     environment ..
(2) Here represented by a ' ' should really be a '\t' (tab).
(3) There is no device we should check at start ..
(4) The single guest home dir .. (or the ftp home) .. and no .. the user
     wont slip out of his home ... Not even to check other guests home ..
(5) The critical part, the filsystem is a "loopback filesystem" ...
    In Solaris (at least 2.5.1) this makes it possible to set up correctly
    chroot's, check the manpages lofs(7FS), mount(2) and vfstab(2).
(6) As we didn't enable the filesystem-check, we don't specify how many
    time the check is run..
(7) We do want it set up right away as the computer boots, right?
(8) We mount it read-only, as the devices should manage anyway ..
    Perhaps we also need 'nosuid' or something, but that is untested.

I also did a (stupid) patch to beta-16 to enable mounting (not
automounting) the dirs right before chrooting .. but that is the
wrong(tm) way to do it .. I got it (untested) if anyone want to look at it
..

-- 
/Emil