Subject: about "guest ftp user"

From: 襄樊热线 <[email-masked]>
Date: Fri, 22 Jan 1999 12:56:47 +0800

Hello,all:

    We uses wu-ftpd version 2.4.2-beta-18,now guest ftp user can be
restricted to it's home directionary.
we do it follows the manual:
    in /etc/passwd,the entry is:
       lixq1998:x:65537:65535::/export/home0/personal/lixq1998:/bin/rsh
    and in lixq1998's home directionary, we have make the following
directionary:
       bin,dev,usr,lib and in them are the related files. So for each
user we have to use more than 1M.
   now i have more than 1000 guest ftp users, so it costs too much,is
there other way to do it and use less space?
    Do you have better one! Please tell me !!!

Thanks.

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 22 Jan 1999 00:41:57 -0500 (EST)

On Fri, 22 Jan 1999, [gb2312] �差���� wrote:

> restricted to it's home directionary. we do it follows the manual:

Method 1:

  All users chroot to a common point.

  Example:

  In /etc/passwd:
    user1::1001:1001::/home/users/./user1:/bin/sh
    user2::1002:1002::/home/users/./user2:/bin/sh
  In /etc/ftpgroup:
    ftpusers::66:user1,user2
  In /etc/ftpaccess:
    guestgroup ftpusers
  In /home/users create bin, dev, lib, etc

  Advantage:

  Only one copy of the common files (bin dev etc lib) is shared between
  all users.  Setup is easy and clean, which solves the disadvantages of
  method 2.

  Disadvantage:

  All users can, via FTP, see into each other's directories.  This risk
  can be reduced by (1) carefull Unix file and directory permissions, and
  (2) user education.

  Also, users can determine the usernames of other users on the system.  
  This information can be used to assist breakins on other user accounts
  (knowing the username is a large part of the battle).  For some sites,
  knowledge of other users may have commercial implications (ie., one user
  finds that their economic competitor is also a user).

Method 2:

  Use hard links.  The setup is exactly as you now have it, but instead of
  copying the files, use ln(1) to create hard-links.

  Advantage:

  Only one copy of the common files.  This method solves the disadvantages
  of method 1 since users each have a separate chroot point.

  Disadvantage:

  Highly complex setup, leading to possible mis-configuration.  In
  addition the hard-link is easily broken, which can be hard to detect,
  leading to inadvertent increase in disk utilization.

Method 3:

  Use NFS or loop-back mounts.  Create a filesystem for each of the shared
  areas (bin dev etc lib).  Export those filesystem via NFS or a loopback
  device.  Mount the filesystems readonly into each user's area.

  Advantage:

  As with method 2.  In addition, with the filesystems mounted readonly,
  site security is enhanced.

  Disadvantage:

  The NFS subsystem has its own security problems separate from those of
  FTP, thus increasing the risk to the host machine while increasing the
  FTP site security.

  Not all systems support loopback mounts.  Those that do may limit the
  number of possible filesystems exported for loopback mount (Linux, for
  instance, has a default limit of 8 such filesystems although you can
  increase this at kernel compile-time).

My recommendation:  For ISPs and IPPs, method 3 is preferable.  If your
system supports loopback mounts, use them.  If you already have NFS, use
it.  Otherwise do not use method 3; use method 2 instead.  For corporate
and home sites, where the users already share a common community, use
method 1.

That said, I will admit that I usually use method 1 on my sites due to the
simplicity of setup.  I find that users generally do not know enough to
find out about each other and most will not blow the Unix-level file and
directory permissions keeping their home directories secure from other
local users.  Those that do are also Telnet users so the point is moot
with them anyway.

-- 

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

---

From: "Speier, Guy J - CNF" <[email-masked]>
Date: Thu, 21 Jan 1999 08:43:57 -0800

I've tried all of this, to no avail.

If you don't mid, I'd like to think aloud (or think with my keyboard at
least).

If I chroot all users to a common area, say /home/ftp/./blah/blah,
and set up my static ls accordingly, all works fine.

If I chroot a user to their home dir, say /home/ftp/./user1,
and ln -f </home/ftp/whatever> </home/ftp/user1/whatever> it doesn't work!
It doesn't even work if I copy the files (instead of using hard links).

I can submit output of truss chroot, ls -lR of both, or whatever.

I appreciate the help!
guy

> -----Original Message-----
> From:	Ted Keller [SMTP:[email-masked]]
> Sent:	Wednesday, January 20, 1999 5:27 PM
> To:	Speier, Guy J - CNF
> Cc:	[email-masked]'; wu-ftpd list
> Subject:	RE: static ls
> 
> All right - I'll try....
> 
> In /etc/passwd, set up each user as....
> 
> usera:x:1029:167:User A:/ftp/users/pub/./:/bin/true
> 
> Create a file /etc/shells and add
> /bin/true
> 
> add the users group to /etc/group
> 
> useragrp:*:167:
> 
> 
> edit ftpaccess to include
> 
> guestgroup     useragrp
> 
> ted keller - bfg.com
> 
> 
> 
> On Wed, 20 Jan 1999, Speier, Guy J - CNF wrote:
> 
> > I still can't seem to get my new chroot point working on Sol 2.6.
> > (trying to chroot each user to their home dir)
> > 
> > The only error I see in all of truss output is a file named
> > /etc/.name_service_door.
> > This is a "door" file (whatever the heck that is).  Would anything else
> help
> > the gods of 
> > wu-ftp help me with this one?  I've even tried to chmod 777 all files in
> the
> > user's
> > home dir (to no avail).
> > 
> > thanks
> > Guy
> >