Subject: Adding FTP module to Apache HTTPD, or reverse engineer Wu-FTPD

From: Cameron Lemon <[email-masked]>
Date: Wed, 02 Dec 1998 14:42:29 -0400

I have submitted an idea to the Apache development group wondering if
they would be
 able to add an FTPD module to the Apache HTTPD.  As Apache provides the
framework,
 adding an FTP module that could utilise access control, connection
throttling,
 daemon routines, stability and such, it would be great if a module
where available.
 Also, Apache could branch off and reuse alot of the Apache HTTPD code,
and insert
 the FTPD code for one kick-ass FTP Daemon.

 Any thoughts on this?

 Cameron Lemon

> Bob Luckin wrote:
>
> > John,
> >
> > >   We've got WU-FTPD 2.4 (yeah, I know it's old, but management is
skittish on
> > > the "beta" tag for the other releases) running fine here.
However, management
> > > now has a new requirement and wants to know if it can be done.  I
don't think
> > > it can, but I want to double check with everybody else:
> > >
> > >         Can WU-FTPD handle directory-level access restrictions?
> > >
> > >   Management is looking for something similar to ".htaccess" for
Apache, but
> > > for WU-FTPD.  I don't think it's do-able because I think WU-FTPD
only does
> > > authentication once, and that's at login.
> > >
> > >   Am I wrong?  Is it possible to do directory-level access
restrictions?  If
> > > so, how would this be done?
> >
> > I'm not aware of a such a feature.  However, you may be able to use
UNIX
> > group permissions to restrict access to specific directories via the

> > SITE GROUP and SITE GPASS commands.  (You'd have to issue the
relevant
> > password to the folks you want to have access to the protected
directory.)
> > For more detail, see the "private yes" command in the ftpaccess man
page.
> >
> > I use this method and it seems to work fine.  Of course, it may be
that
> > this solution is not suitable for your particular problem...
> >
> > Cheers, Bob

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 2 Dec 1998 15:19:21 -0500 (EST)

On Wed, 2 Dec 1998, Cameron Lemon wrote:

> they would be able to add an FTPD module to the Apache HTTPD.  As
> Apache provides the framework, adding an FTP module that could utilise
> access control, connection throttling, daemon routines, stability and
> such, it would be great if a module where available. Also, Apache
> could branch off and reuse alot of the Apache HTTPD code, and insert

I've heard from some of the Apache folk in the past, and they've asked
along the same lines, so the idea isn't new.  In fact, I've thought about
it quite often over the past two years or so.

As I read your message, I see 'they would be able to add' .. I think the
answer to that is probably going to be: You write it, and submit it to the
module registry, and they'll be happy.  I seriously doubt they'll write it
for you.

Personally, merging FTP and HTTP into a single daemon seems like feature
bloat.  Sure there's a lot of similarity, but it would be better to grab
what works from the Apache source kit and dump the rubbish (from FTP's
point of view).  Really, do you need content negotiation for FTP?  I'm
sure there's a lot of other features of Apache which have nothing to do
with FTP but content negotiation is what they're talking about today, so
it's in my mind.

As for access control, the new FTP specifications will make it imperitive
the daemon upgrade the view of the file system.  Along with that will come
access control.  From what I've seen, the Apache model will not lend
itself to the full virtual file system envisioned by the new FTP so the
entire file access and file access control system in Apache is probably a
write-off.

If you mean user-level access control, the FTP protocol does not lend
itself to much more than a simple login, do whatever, logout model.  While
some daemons allow multiple logins in a single session, with wuftpd it's
not possible since upon login the daemon chroot's and the authentication
subsystem is no longer fully available.  This is one of the most
significant strengths to wu-ftpd and I'd be loath to see it go away.

What we're left with from Apache is a base of code which accepts and
manages connections, spawning and managing processes (threads, maybe
someday) to serve those connections, and a few support functions.

All in all, I'd estimate that less than 20 percent of the Apache core code
would survive.  At that rate, it's easier to lump Apache in with Bind and
Sendmail .. it's a good place from which to yank specific working
functions, but it's not a good place to leap off from for a new project.

Alright?  I've got my flame-retardant suit on ...

-- 

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

---

From: Cameron Lemon <[email-masked]>
Date: Wed, 02 Dec 1998 18:06:35 -0400

> it quite often over the past two years or so.

There are very few new ideas these days.  Somebody usually beats you to it
whether you know it or not.

> module registry, and they'll be happy.  I seriously doubt they'll write it

Should have caught "they would be able to add" before I clicked on 'send'.

> with FTP but content negotiation is what they're talking about today, so

Not necessarily enclose both daemons within the same daemon, but base FTPD
upon the model of Apache HTTPD.

> entire file access and file access control system in Apache is probably a

Oh.

> significant strengths to wu-ftpd and I'd be loath to see it go away.

I agree.

> Alright?  I've got my flame-retardant suit on ...

You won't need your suit for this one as there are more than enough flammers
giving hell to anyone that'll listen, plus you didn't hurt my feelings by
airing your concerns in a logical fashion.  The idea utilising some of the
Apache code/functionality was just a brain-fart myself and a collegue had
while chowing down at a local Italian restaurant, and was far from
investigated thoroughly.  Maybe the garlic affected our power of reasoning.
;-)

<brain-fart close>

Cameron Lemon

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 2 Dec 1998 17:29:54 -0500 (EST)

On Wed, 2 Dec 1998, Cameron Lemon wrote:

> The idea utilising some of the Apache code/functionality was just a
> brain-fart myself and a collegue had while chowing down at a local
> Italian restaurant, and was far from investigated thoroughly.  Maybe
> the garlic affected our power of reasoning. ;-)

Garlic?  For me it's usually the .. er .. 'oregano' I smo .. um ..
consume when I get a brilliant flash like that.

Seriously .. while I personally am opposed to the idea of merging WU-FTPD
and Apache it's not because I've been working on the code or have any love
for the code.  Let's face it, the code for both sucks but the code for
Wu-FTPD sucks far harder.  I work with it because it's there and I'm not
(yet) inclined to toss it all.

I guess my major objection is _this_ is wu-ftpd.  Warts and all.  It may
not be pretty but it's what we all know.  It does one job and does it well
so, except for those few of us who actually _like_ to tinker, it's all
that's needed.

I remember reading (somewhere, don't remember where) on the Information
Superhighway, Apache is the Ferrari (neat, sexy, fast .. what everyone
wants) where WU-FTPD is a Mac truck (it aint pretty, it's sometimes slow,
but it hauls the freight and gets the job done).  I like this analogy a
lot.  Apache's primary job is shovelling a large number of small files out
the door as quickly as possible.  FTP, on the other hand, is meant to push
massive amounts of information.  Sure either can do the others job, but
the design goals and implementation choices for each should reflect that
basic difference.

If one were to implement it on the Apache model using Apache's runtime
support as much as possible, I rather doubt it would have any resembalance
to wu-ftpd.  In fact, why bother with wu-ftpd at all?  All you'd really be
using is the name.  It would be better, especially considering the baggage
you'd be picking up with the Apache code base, to lose the baggage of
wu-ftpd and make a fresh start.  All it takes is someone with the will,
the time, and the programming abililty.

--