Subject: Re: chroot is not working for guest users

From: [email-masked]
Date: Thu, 29 Apr 1999 08:49:08 +0200

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

> > 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
>
> 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.
>
> > > I would like to create a ftp server in AIX and have different users
> > > accessing only their home directories (to chroot to $HOME).
>
> > > 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.
>
> 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: Susannah Gort <[email-masked]>
Date: Thu, 29 Apr 1999 17:00:51 -0700

I too have been wrestling with the guest user problem.  In my
ignorance, I was using the non-VR wu-ftpd 2.4.2.  I've upgraded
to VR17 and changed my configuration according to the
wonderful instructions Greg gave Steve, which happen to 
cover almost exactly the same situation that I am working
with.  But I still have the problem that I had before, which
I can't find any mention of in the FAQ or the mailing list
archive.

All my users are guests (no anonymous here).  User logs in.
User is correctly chrooted to /usr/local/ftp, and correctly 
confined to its home directory, say /usr/local/ftp/testlusr.
So far all is great! This user, by the way, is in class 'cust'. 

Now I test uploading files.  I have the following upload
directives in /etc/ftpaccess.

upload class=cust /usr/local/ftp/* / no
upload class=cust /usr/local/ftp/* /* no
upload class=cust /usr/local/ftp/* /*/toarti yes artiftp artiftp 0660
upload class=cust /usr/local/ftp/* /*/fromarti yes artiftp artiftp 0660
upload class=cust /usr/local/ftp/* /*/* no

The user 'artiftp' is in /usr/local/ftp/etc/passwd and the
group is in /usr/local/ftp/etc/group.

The upload directives work in so far as the user is only
allowed to upload files into the directories
/usr/local/ftp/testlusr/[to|from]arti.
The group ownership of the files and the permissions
are all correct.  But the files are owned by root.
What gives?

Susannah

---
Susannah Gort, Senior Systems Administrator, Artisan Components, Inc.

Arnt Agatha she say: Yew can't storp trouble from comin round, but
yew dorn't hev to give hem a chair ter sit orn.

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 30 Apr 1999 09:22:23 -0400 (EDT)

On Thu, 29 Apr 1999, Susannah Gort wrote:

> The upload directives work in so far as the user is only allowed to
> upload files into the directories
> /usr/local/ftp/testlusr/[to|from]arti. The group ownership of the
> files and the permissions are all correct.  But the files are owned by
> root. What gives?

Dunno.  works for me.  Check your local passwd and group files
(/usr/local/ftp/etc/passwd) .. is there a username artiftp and a gorupname
artiftp there?  I'm anal about making sure all that stuff appears where
it'll be used, maybe it's not there and the daemon is quietly using
uid/gid 0 (root) and a (very bad) second choice.

If that's the problem, let me know.  It's such a BAD second choice, I'll
put together a patch to disallow uploads rather than use uid/gid 0.

If it's not, let me know and I'll play a bit on my test server to see if I
can figure out what's going on.

--

---

From: Susannah Gort <[email-masked]>
Date: Fri, 30 Apr 1999 09:29:48 -0700

> uid/gid 0 (root) and a (very bad) second choice.
/usr/local/ftp/etc/passwd:

artiftp:*:300:302::/:
ftpacct:*:301:301::/:
testarti:*:303:301::/:
testlusr:*:302:301::/testlusr:

/usr/local/ftp/etc/group:

ftp::301:
artiftp::302:
nobody::60001:
noaccess::60002:
nogroup::65534:

What makes this even more odd is that it's finding the artiftp
/group/ - I don't see how it could be finding one and not the
other.  Unless I've done something so incredibly stupid that
I can't see it.  Both files are world readable, so it's not that.

> put together a patch to disallow uploads rather than use uid/gid 0.
I agree, it's a wretched second choice, if that is what it's doing.

> can figure out what's going on.
Thanks!  If you need the whole ftpaccess file, let me know.