Subject: Re: Upload with guestgroup

From: Lutz Henckel <[email-masked]>
Date: Tue, 02 Mar 1999 10:38:24 +0100

Gregory A Lundberg wrote:
> 
> On Fri, 26 Feb 1999, Lutz Henckel wrote:
> 
> > /etc/passwd contains:
> >       guest:x:5000:5001:FTP Guest:/usr/ftp/./pub/guest:/bin/sync
> >
> > /etc/group
> >       group::5001:
> 
> Add guest to group in /etc/group:
> group::5001:guest
> 

Thanks, you are right but this does not solve the problem.
The guest user will be chroot'd to /usr/ftp but the upload restrictions
does not have any effect. Furthermore it is possible to create
directories
and the uploaded files get the permissions and ownership as
guest would be a real user.

I have tested the older VR versions with the identical configuration
file (ftpaccess) under Linux and it works until VR5. The newer versions
does not work as it is expected.

-- 
Lutz Henckel                 Phone  : ++49 / (0)30 / 3463 - 7237
GMD FOKUS                    Fax    : ++49 / (0)30 / 3463 - 8237
Kaiserin-Augusta-Allee 31    E-Mail : [email-masked]
D-10589 Berlin, Germany      WWW    :
http://www.fokus.gmd.de/usr/lutz.henckel

---

From: Gregory A Lundberg <[email-masked]>
Date: Tue, 2 Mar 1999 08:04:35 -0500 (EST)

On Tue, 2 Mar 1999, Lutz Henckel wrote:

> file (ftpaccess) under Linux and it works until VR5. The newer
> versions does not work as it is expected.

VR5 is when the fixes for the upload clause went in.  Earlier versions of
the daemon, as it moved from 2.3 (I don't have anything earlier to look
at) to beta-18, went through different bugs in how upload worked.

Before there was 'guestgroup' the <root> parameter meant the chroot point.
That was either '/' or the ftp user's home.  Seemed clear enough.

When guests came along, it stayed documented as the 'root' but it was
really the home directory.  This caused confusion when the '/./' hack was
added.  First off, it used a strcmp against the passwd file, so you had to
put the /./ on the upload clause.  Second, if you read the docs, you only
put in the root (chroot point) and got angry if you noticed it wasn't
working.

Then came the ALTERNATE_CD patch (somehere like beta-17) which rewrote the
pw->pw_dir entry with the relative home after chroot.  That broke the
comparison completely.  Now you had to put in the home relative to the
chroot.  That lead to ambiguous rules.

Confusion reigned until VR5 when I'd had enough.  My first attempt was to
believe the docs; only use the root, the chroot.  Sure it behaved like
very old versions, but didn't handle by-user rules.  OK, then try the
relative path.  That made for ambiguous rules since two users could easily
appear the same now (/home/users/jim and /home/staff/jim, different jim
but user jim's rules applied to staff jim).  This was like later beta
versions and unacceptable.  Finally I realized that the problem was
twofold, the '/./' and the chroot.  To convert the names to something
comparable, I ran everything through realpath().  To handle chroot, I
prepended the chroot point to the cwd, pw->pw_dir and the parameters given
via ftp commands.  Worked great.

Problem is, depending on the version you're upgrading from and what upload
clauses you had .. and whether they ever worked at all (you'd be amazed
how many didn't but the Unix permissions did so nobody noticed) .. the new
method could break things.  I thought long and hard and decided it was
better to break a few working sites than to let the confusion reign.

One of the things it broke, big time, was anyone using Ketn's NEWVIRT.
That meant BeroFTPD.  After a lot of discussion with Bernard about how
NEWVIRT handled the problem, I added an optional first parameter to
upload.  With it, the <root> parameter could be declared 'relative' to the
current chroot.  Since then I've added a few other things to the optional
first position, like class-only selection.  If other things come along
which make sense for upload, I'll be adding them into that optional first
(series of) parameter(s).

I've written ftp://ftp.vr.net/pub/wu-ftpd/upload.configuration.HOWTO which
shows how to set up the upload clause.  Most likely you just need to
change the <root> parameter to use the full realpath from the system root.

-- 

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