I see your point in seeing if ftp is the solution is really what we want. 
And you did agree that you did not know our business situation.

It's needed.  We want to share drawings with business partners.  And some 
EDI based data goes in/out that way also with other trading partners. Yes, 
perhaps we could beat it to death in other fashion to get around using 
ftp, but I'm not sure that it would be programming for the best solution, 
or programming to get around using FTP.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/18/2005 08:01 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc

Subject
RE: iSeries FTP security






> From: Evan Harris
> 
> 
> I am fairly sure I understand how FTP works, although I will confess
to
> not being particularly aware of the ".." exploit.

These are somewhat contradictory statements.  If you don't know the
basics of the IFS (or any hierarchical file system), then you really
don't know much about how the FTP server or any of the other Unix-like
utilities works.  You may know how to use the FTP client, but you really
don't know that much about FTP.

That aside, I see your dilemma.  You have an NT guy who says he can make
data available simply and easily, and you have to compete with that.
However, the more I look at that argument, the more I have a problem.

Your primary argument boils down to this: if I don't do what the NT guy
says HE can do, then I will lose the iSeries.  That's really the crux of
the biscuit: you have to keep up with the NT guy or else your company
will abandon the iSeries.

If this were entirely true then you would have no control over security
and access to your data.  You simply have to do whatever the NT guy says
he can do.  This to me is frightening.  Since the SQL guy can also just
as easily update the data, do you have to allow update access as well?
If not, why not?  Probably because you can make a reasoned argument that
you need business rules to protect the integrity of the data.  But the
point is that you don't have to do everything the NT guy says.

So the real issue is not keeping up with the NT guy, it's providing fast
access to the data.  Why do you need fast FTP access to your data?  In
what situation does it make sense to download entire files to some other
machine?  How many rows are we talking about?  If it's not that many
rows, how long does it take to make a copy?  If it's a lot of rows,
wouldn't it be faster to download only a portion of the data?  And in
that case, you're no longer talking FTP.

Really, I'm interested to know what purpose is served by FTP that can't
be handled with 15 minutes of programming, or how big a file it is that
copying it to a holding area actually takes too long for the end user.

The point is not that you don't have a legitimate need for FTP, Evan.  I
don't know your shop.  I'm just pointing out that the majority of uses
I've seen of FTP are simply to save the IT guy some time, and it's done
at the expense of security.

And as I've always said, those who are willing to sacrifice security in
order to make their job a little easier deserve neither.

Joe

-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.