Subject: RE: Trigger of an executable upon file send complete

From: DJ <[email-masked]>
Date: Wed, 30 Sep 1998 11:05:58 -0700

Yes, this gets quite complicated.
Also very complicated are issues of triggering these things for
anonymous users or under different user IDs, because you may
be chrooted and want the program to exec somewhere else under
a different userID.  It is impossible to get back out of a chrooted
environment to run the program elsewhere outside that environment.
Then you get into issues of transactionally reporting the success/failure
of the program to the client that sent the file, etc, etc.

We spent 2 years building this capability into our commercialized
version of wu-ftpd called FileDrive EX.  www.filedrive.com
We ended up making it support distributed computing, so you can
run the programs on a different server altogether, based on
userid, filename, etc.

DJ
Differential, Inc.
Accelerating Extranet Commerce
www.differential.com

At 12:53 PM 9/30/98 CDT, Bob Luckin wrote:
>Gregory said :-
>> > What are your requirements?  Same exe?  Exe based on file?  Different
>> > exe depending on sucess or failure of transfer?
>> 
>> I'd like to suggest the following syntax:
>> 
>> onupload [success|failure|-] <fileglob> <uid> <gid> <exename>
[<parameters> ...]
>> 
>> Where:
>> 
>> [success|failure|-] optional parameter, only execute if success or
>> failure, or anytime.  The - is to avoid confusing the option with a file
>> named 'success' or 'failure'
>> 
>> <fileglob> required, pass to fnmatch, execute if !fnmatch .. only when
>> matched.
>> 
>> <uid> and <gid> required, the user/group to execute the program as.
>
>In addition to being able to force it to run with a known specific uig/gid,
>you also need to allow the ability to run as the current user and/or group
>(whoever it may be), especially on sites where real users are allowed.
>I guess you could use a "-" to specify this, similar to your proposal for
>the success/failure option.  Or you could use "%U" and "%G", similar to your
>"%F" proposal for the upload file name...
>
>I'm not really fussy about how you specify it, but you do need to allow
>this option.
>
>
>And following on from this, some site admins will probably want to be able
>to specify - for each onupload line - which users or classes of users
>that feature should be applied to, so that anyone else uploading the file
>does not trigger the execution of the program.
>
>The most flexible way of doing this is probably to supply a regexp (which
>may be quite complex) which indicates which userids and/or groupids the
>command applies to.  (Including a form which says apply it for everyone
>_except_ those which match the regexp.)
>
>Hmm...  I'm glad I don't need this feature at the moment !
>
>Cheers, Bob
>-- 
>Bob Luckin    [email-masked]    "Many hands make a heavy arm"
>
[http://www.dhc.net/luckin/cgi-bin/misfortune.cgi]

---

From: Gregory A Lundberg <[email-masked]>
Date: Wed, 30 Sep 1998 14:41:16 -0400 (EDT)

On Wed, 30 Sep 1998, DJ wrote:

> Yes, this gets quite complicated. Also very complicated are issues of
> triggering these things for anonymous users or under different user
> IDs, because you may be chrooted and want the program to exec
> somewhere else under a different userID.  It is impossible to get back
> out of a chrooted environment to run the program elsewhere outside
> that environment. Then you get into issues of transactionally
> reporting the success/failure of the program to the client that sent
> the file, etc, etc.
> 
> version of wu-ftpd called FileDrive EX.  www.filedrive.com We ended up
> making it support distributed computing, so you can run the programs
> on a different server altogether, based on userid, filename, etc.

All of which is beyond what 90% of the users want.  What people are asking
for is the ability to email a notification, or run a checker.  Granted,
the FTP protocol can be used to transport transactional information
between machines; but that does not mean the daemon needs to support it.
If we view the machine as a black hole, into which files are dropped, and
on whichthe remote user does not know, or even care, that a post-
processing program may be run against the file, we avoid a lot of these
complications.

Almost invariably, these programs run in a chroot'd environment; so
there's not a lot it _can_ do.  Frankly, I expect the use of this feature
to be the source of a VAST number of questions on the mailing list. That's
not to say the feature is inherently bad; just that once people start
playing with it, stand back!

For security, the site admin needs to be able to have the program run as
some known user.  Personally, I don't even like the idea of running it as
the currently logged-in real user.  I certainly do not think it should run
as the logged in guest/anonymous user.  Even allowing it to run as a real
user, I still would NEVER allow a user to provide their own programs.  If
users want that much flexibility, they should use the Apache and suEXEC.  
Wu-FTPD has _way_ too much privilege to allow that knd of activity.

Success or failure of the program can easily be mailed to some responsible
party.  The server's a block hole.  Files appear and are dropped off at
random times.  If the program needs to communicate, mail is easy and quite
fast enough.

Finally, if you need all those fancy features which DJ's company  worked
so hard to get in, it's far easier to implement them in a stand-alone
external program than inside the daemon.  I say, exec the program and let
it deal with the complications.  The job of the daemon is not to be all
things to all people, it's to provide enough of a platform that the job
can be done.  If we keep sight of that, it's not all that complex a
feature and fairly simple to implement.

-- 

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