Subject: RE: ftpconversions

From: [email-masked] (Geoff Terry Systems & Net supt 064 923677)
Date: Fri, 28 Feb 1997 12:06:36 +1100 (EST)

David,
Yeah your right, I didn't think about it to much.

Regards Geoff

>That's a clever approach!  But wouldn't the ftpd send them the script
>rather than executing it?
>
>Dave
>
>
>> -----Original Message-----
>> From:	[email-masked]
>> [SMTP:[email-masked]] On Behalf Of [email-masked]
>> Sent:	Thursday, February 27, 1997 4:00 PM
>> To:	[email-masked]
>> Subject:	Re: ftpconversions
>> 
>> David,
>> Why not create hard links (using the target file names) to the perl
>> script,
>> which then does the mod and returns the target file (from some unseen
>> directory).
>> Of course the problem will be that all targets will hame same owner,
>> permissions and file size, date etc attributes, so knowlegable users
>> will
>> become sus and think either the files are wrong or start looking
>> around.
>> 
>> Regards Geofft
>> 
>> 
>
>
Geoff Terry    Systems & Network Support
ACR Net        Sapphire Coast NSW 2550
Australia
Ph 064 923677  Mobile 015 668 227 Fax 064 924594

---

From: Alain Magloire <[email-masked]>
Date: Thu, 27 Feb 1997 20:34:07 -0500 (EST)

Bonjour

>I'm trying to figure out a way to set up an FTP server that will run a
>perl script to modify certain files before they are sent, while
>preventing any access to the original files.  Ideas, anyone?

first:
#include "disclaimer.h"
I didn't test this.

You could add a rule in ftpconversions for certain
extension ex: .fl

 :   : :.fl:/bin/program %s:.....

if you have:
/home/ftp/pub/file <----- an empty/dummy file
/home/ftp/pub/.hidden/real.file <---- the real file :-)

when the client issued

ftp>get file.fl

the conversion mechanism should be trigger
and the client should receive the stdout of program

-- 
au revoir, alain
_______P_________O____________I______R___________E___
POIRE: Premature Optimization Is the Root of all Evil
                     D.K or is it B.K ? maybe A.M ;-)

---

From: Bob Luckin <[email-masked]>
Date: Thu, 27 Feb 97 20:08:23 CST

Alain  suggested :-
> and the client should receive the stdout of program

One trouble with this is that if a user lists the pub directory (at least
with the dir command) they may see the ".hidden" directory, and go in there
and pull the real file directly, skipping the conversion.  But you can
partially get round this by making the directory searchable but not readable
(d--x--x--x, or drwx--x--x).  Then they will at least have to be clever
enough to guess that there is a "real.file" inside (ie. know what name to
use).

Another problem is that some users will list pub, see the empty file and
try to get that instead of file.fl - ending up with an empty file.  If you
have users who don't fully read the instructions you send them, and just cd
to the directory and pull what they see there, you're likely to end up having
to deal with a number of complaints about empty files.  The same is true if
your users tend to browse around the system and pull any files they see
with interesting names...

But if you can live with this, then I think Alain's suggestion will work
(bon idee !) - but his disclaimer also applies to me  :-).

Cheers, Bob
-- 
Bob Luckin      [email-masked]      "A man, a plan, a canal, Suez !"

---

From: Jasmine Yeap <[email-masked]>
Date: Fri, 27 Sep 1996 23:34:11 +1100

I was running wu-ftpd 2.4 before I upgrade to wu-ftpd-2.4.2-beta-12.
Now, I found that my guest group user does not get the 
chroot() when the access the ftp server. Can someone help?
It was working fine before I upgrade it. I'm running
on Solaris 2.5.1 on Sun Ultra 1 machine. When I do a 
ckconfig, I get exactly same output as my old version of
ckconfig. By the way, I use the version 2.4's src/pathnames.h
to compile wu-ftpd-2.4.2-beta-12. Could this be the problem?
Would appreciate any suggestion. Thanks.

regards,
Jasmine

---

From: Michael Brennen <[email-masked]>
Date: Fri, 28 Feb 1997 00:23:44 -0600 (CST)

Check and see if the -a is on the wu.ftpd command line in inetd.conf.

Additional FAQ info is below.

   -- Michael

> Would appreciate any suggestion. Thanks.

This is the location for the latest wu-ftpd.  You can't see the
directory contents, but get the file anyway.  It's there.

ftp://ftp.academ.com/pub/wu-ftpd/private/wu-ftpd-2.4.2-beta-12.tar.Z

wu-ftpd FAQ:  http://www.cetis.hvu.nl/~koos/wu-ftpd-faq.html
              OR
              send mail to [email-masked]
              with a subject line: send faq

guest howto:  ftp://ftp.fni.com/pub/wu-ftpd/guest-howto
              OR
              send mail to "[email-masked]"
              (immediate autoresponder; subject does not matter)

wu-ftpd list archive:  http://www.landfield.com/wu-ftpd/mail-archive/

There are additional security references in the above docs.

---

From: Gregory Youngblood <[email-masked]>
Date: Fri, 28 Feb 1997 00:57:28 -0600 (CST)

First make sure that you are calling wuftpd with the -a option from inetd 
(if that is how you run). The default behavior changed and now the -a 
option is required to use the ftpaccess file.

Note, however, that when I made the same upgrade as you, my chroot() 
guest user also quit working. I have had to remove the upgrade and return 
to 2.4.

---

From: Jasmine Yeap <[email-masked]>
Date: Sat, 28 Sep 1996 00:27:38 +1100

> guest user also quit working. I have had to remove the upgrade and return

Dear Gregory,
     Thanks for your reply. Yes, I miss out the -a option for
inetd. Once I add the -a, it just work fine. By the way,
did you restart your inetd after you make the changes?
Well, you need to "kill -l" for inetd for the changes to
take effact. Well, for my case, I just reboot my server.

     Also, is your ftpaccess in the correct place? do a
ckconfig to check if it reads the correct file. Good luck.

regards,
Jasmine