Subject: chroot is not working for guest users

From: [email-masked]
Date: Wed, 28 Apr 1999 14:22:36 +0200

Hi,
I have downloaded wuftp (Version wu-2.4.2-academ[BETA-18-VR14](1) from
www.bull.de/pub/aix432) and I'm trying to see if it can fullfill my
"wishes".

I would like to create a ftp server in AIX and have different users
accessing only their home directories (to chroot to $HOME).

Let say the anonymous ftp has its root dir in /home/ftp. When another user,
let say kalle, is ftp'ing to the machine he should be seeing
/home/ftp/kalle only and nothing above that.

I've been trying to access information about wuftp to accomplish that, but
haven't found anything that helps......

The issue I have is that I'll get to /home/ftp/kalle, but I can still do a
"cd .." and see the directories above $HOME of the kalle. I can even go
down in other users $HOME which is what I want to prevent.

This is my config :
-------------

/etc/inetd.conf:
ftp     stream  tcp4    nowait  root    /usr/local/bin/ftpd     ftpd -a

/etc/passwd (all AIX users defined):
.
kalle:!:214:201::/home/ftp/./kalle/:/etc/ftponly
otto:!:215:201::/home/ftp/./otto:/etc/ftponly
anonymou:*:216:1::/home/ftp:/usr/bin/ksh

/etc/group (all AIX groups defined):
system:!:0:root
.
ftpgroup:!:201:otto,kalle

/etc/ftpaccess:
class   all   real,guest,anonymous  *
#class  remote  kalle,otto

#limit  kalle   1       Any     /home/ftp/kalle
#limit  otto    1       Any     /home/ftp/otto
limit   all   10   Any              /etc/msgs/msg.dead

readme  README*    login
readme  README*    cwd=*

message /welcome.msg            login
message .message                cwd=*

# how to check password? Use "enforce" instead of warn to refuse access
passwd-check rfc822 warn

# You need to copy "compress" and "gzip" into the directory
#   ~ftp/bin/ftp-exec to get this to work.....
compress        yes             all
tar             yes             real guest

# command logging goes to syslog,
# transfer logging goes to /var/adm/ftpd/xferlog (use xferstats to display)
log commands real
log transfers anonymous,real inbound,outbound,kalle

path-filter anonymous /etc/pathmsg ^[-A-Aa-z0-9_\.]*$ ^\. ^-
path-filter guest /etc/pathmsg ^[-A-Aa-z0-9_\.]*$ ^\. ^-

guestgroup ftpgroup

shutdown /etc/shutmsg

email user@hostname

/etc/security/login.cfg (has /etc/ftponly defined, as it's not using
/etc/shells):
usw:
        shells =
/bin/sh,/bin/bsh,/bin/csh,/bin/ksh,/bin/tsh,/usr/bin/sh,/usr/bi
n/bsh,/usr/bin/csh,/usr/bin/ksh,/usr/bin/tsh,/usr/sbin/sliplogin,/usr/sbin/
uucp/
uucico,/etc/ftponly
        maxlogins = 16
        logintimeout = 60

Files in /home/ftp/kalle:
find . -ls
10450    1 drwxr-xr-x  8 kalle    staff         512 Apr 28 07:10 .
10455    0 -r--------  1 root     system          0 Apr 28 07:10 ./.rhosts
 8483    1 d--x--x--x  2 root     system        512 Apr 27 16:12 ./bin
 8484   19 ---x--x--x  1 root     system      18774 Apr 27 16:12 ./bin/ls
 8485    1 d--x--x--x  2 root     system        512 Apr 27 16:12 ./dev
 8486    0 -rw-r--r--  1 root     system          0 Apr 28 12:37 ./dev/null
 8487    1 d--x--x--x  2 root     system        512 Apr 28 08:06 ./etc
 8488    1 ---x--x--x  1 root     system         72 Apr 28 11:59
./etc/passwd
 8490    1 ---x--x--x  1 root     system         33 Apr 28 12:45
./etc/group
 8489    1 -rwxr-xr-x  1 root     system        746 Apr 27 16:12
./etc/ftponly
20759    1 d--x--x--x  2 root     system        512 Apr 27 16:13 ./lib
20760 5792 -r-xr-xr-x  1 root     system    5930595 Apr 28 12:37
./lib/libc.a
20761 1608 -r--r--r--  1 root     system    1643383 Apr 28 12:37
./lib/libcurses.a
20762   11 -r-xr-xr-x  1 root     system      11167 Apr 28 12:37
./lib/libcrypt.
a
 2092    1 d--x--x--x  2 root     system        512 Apr 27 16:13 ./pub
 2228    1 d--x--x--x  3 root     system        512 Apr 27 16:13 ./usr
 2229    1 dr-xr-xr-x  3 root     system        512 Apr 27 16:13 ./usr/lpp
 2230    1 dr-xr-xr-x  3 root     system        512 Apr 27 16:13
./usr/lpp/msg
 2231    1 dr-xr-xr-x  2 root     system        512 Apr 27 16:13
./usr/lpp/msg/sv_SE
10459    0 -r--------  1 root     system          0 Apr 28 07:10 ./.forward

/home/ftp/kalle/etc/passwd has only 2 lines:
root:!:0:0::/:/bin/ksh
kalle:!:214:201::/home/ftp/./kalle/:/etc/ftponly

/home/ftp/kalle/etc/group has only 2 lines:
root::0:root
ftpgroup::201:kalle

I would appreciate help.

Thanks in advance

Med vänliga hälsningar / Best regards
Michael Karman
E-mail: [email-masked] alt. [email-masked]
Phone #: +46-8-7932134
Cell phone #: +46-70-7932134

---

From: Steve Saul <[email-masked]>
Date: Wed, 28 Apr 1999 07:41:24 -0500

There are perhaps more elegant ways (I'm relatively new at this too),
but if you move the "/./" to after kalle and after otto in /etc/passwd,
you should get what you need - i.e.:

kalle:!:214:201::/home/ftp/kalle/./:/etc/ftponly
otto:!:215:201::/home/ftp/otto/./:/etc/ftponly

Hope this helps,

Steve

---

From: "Danny N." <[email-masked]>
Date: Wed, 28 Apr 1999 12:09:21 -0500 (CDT)

i'm currently have this same problem...

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 28 Apr 1999 13:34:45 -0400 (EDT)

On Wed, 28 Apr 1999, Steve Saul wrote:

> but if you move the "/./" to after kalle and after otto in
> /etc/passwd, you should get what you need - i.e.:
> 

This will fix the problem but at the cost of having to set up bin, etc,
dev, lib (at al) areas in each user's home directory.

> > down in other users $HOME which is what I want to prevent.

Here's how to do it using full-on VR17 .. what?  you're not running VR17?
Well upgrade, silly:

The location of the latest versions of wu-ftpd can be found in the 
directory
 
      ftp://ftp.vr.net/pub/wu-ftpd/
 
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/

First, read the FAQ and the guest HOWTO.  Set up a user, just one for now,
as a guest just like they tell you to.  Make sure it works, ls et al, and
they're chroot'd .. don't worry about the ability to browse other users'
homes yet.

Now, take a look at your users.  You want them all to be guests.  Are they
all in the same area (/home/ftp ?)  Yes.  Good.  Add the following lines
to your ftpaccess:

guestuser *
realuser ftp
guest-root /home/ftp

This says "Everyone is a guest except anonymous FTP users, and all guests
are chroot'd to /home/ftp."

BTW, you can lose the '/./' hack in /etc/passwd after you do this: the
daemon won't care any more.  And take out the guestgroup clause and the
group from /etc/groups .. the daemon won't be using them any more either.

Now, your users can still look in each others' homes.  Not good.  Let's
stop it.  Add the following to your ftpaccess:

restricted-uid *

"Everybody is restricted to their home directory."  Except anonymous
users who are not effected by this clause.

One last thing: make sure the home directory entries in
/home/ftp/etc/passwd are correct >>from the point of view of the chroot<<
for example:

kalle::214:201::/kalle:
otto::215:201::/otto:

After you do all this, if any of your users were coming in via Navigator
or IE, they will need to click 'Refresh' to get a new copy of their FTP
areas .. the cached copies are now wrong.

-- 

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

---

From: Steve Saul <[email-masked]>
Date: Wed, 28 Apr 1999 12:20:04 -0500

Greg,

Thanks for the amplification on my reply (I should have mentioned the
various support files).

Thanks also for your more rigorous solution - a great template for the
structure I'm currently setting up.

Steve

---

From: Mike W Ellwood <[email-masked]>
Date: Wed, 28 Apr 1999 20:12:05 +0100 (BST)

> dev, lib (at al) areas in each user's home directory.
<snip>
> Here's how to do it using full-on VR17 .. what?  you're not running VR17?
<snip> 
> users who are not effected by this clause.

Have I understood correctly? Do you recommend this scheme
as a general way of setting up guest users, or just in
this particular case?

If so, it seem to remove the useful concept of a guest
user, i.e. something in-between anonymous and real,
whom you can tie down to a fixed directory and view of
the world.

Whereas I want to be able to make my "real" users
have as much access as they would if they were logging in.
-- 
[email-masked]

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 28 Apr 1999 15:50:18 -0400 (EDT)

On Wed, 28 Apr 1999, Mike W Ellwood wrote:

> Have I understood correctly? Do you recommend this scheme as a general
> way of setting up guest users, or just in this particular case?
> 
> If so, it seem to remove the useful concept of a guest user, i.e.
> something in-between anonymous and real, whom you can tie down to a
> fixed directory and view of the world.
> 
> Whereas I want to be able to make my "real" users have as much access
> as they would if they were logging in.

I recommend:

 - NO REAL USERS.  Nadda.  Zip.  Zero.  Everyone is a guest and if they
   don't like it tell 'em to go buy their own copy of Linux and stop
   bothering you 'cause you got a system to keep running.  If they wanna
   Trojan your system, make log in so you _KNOW_ it was them.

 - OK, so _one_ real user .. You, the ftp site administrator.  But only if
   you trust yourself.  Be honest, though.  You shouldn't even be using
   FTP you should be using ssh/scp to manage the machine, so what's the
   problem?

 - All guest users be chroot'd to a common point so you don't have a whole
   mess of copies of bin/ls bin/tar etc/passwd and so forth.  Life's hard
   enough, why make it harder?

 - All users, real or guest, be restricted to their home directories.  If
   they need to share files, mount a common filesystem in each of their
   homes.

With VR17, you don't have three types of users any more.  You have FIVE.
Or you can think of it as two different ways to chroot a user.

1) Anonymous users, chroot'd to the anonymous area

2) Restricted guest users, chroot'd to a common point and restricted to
   their homes .. to the user it looks like they're chroot'd to their
   home.

3) Unrestricted guest users, chroot'd to a common point.  They can browse
   each other's homes to their heart's content but cannot reach outside
   the chroot'd area.

4) Restricted real users.  Not chroot'd but restricted to their homes
   anyway.  It will look to them like they're chroot'd but they're not.
   You can do this, but I don't think it's very safe.

5) Unrestricted real users.  Not chroot'd and not restricted.  Any fool
   who does this deserves exactly what he's gonna get .. hacked.

I'm saying a well-managed FTP site has any number of users of type (1) and
(2) but no more than a single person, the ftpadmin, as type (4).

--