Re: Distros

[Steven Pritchard <steve@silug.org>]

On Wed, Nov 06, 2002 at 10:09:30PM +0000, mike808@users.sourceforge.net wrote:
> I don't understand how something that is hard for firewalls makes a
> protocol "error prone".
[...]
> Passing IP addresses and ports over a connection makes FXP transfers
> easy, but traversing firewalls and NAT is a real PITA.

The crufty part comes from doing things that make it next to
impossible to NAT or firewall connections.

> I'm not saying there's nothing wrong with FTP. Two connections is quite
> smart. Synchronizing them isn't easy.

It's a royal pain in the ass.

> Is rsh/rlogin "worse" because it's error-prone or hostile to
> firewalls?

No, rsh is just Evil because it leaves all authentication to the
*client* (instead of the server).  It sucks because it also requires
two TCP connections (one for stdin/stdout, the other for stderr and
sending signals).

I once started writing a Net::Rsh perl module.  I actually had working
code, but gave it up when I realized just how bad of a joke rsh was.

BTW, if you've ever wondered how rsh works, here's what I remember off
the top of my head...

    1) The rsh client binds to a low port and listens for connections.
    2) It binds to another low port and connects to the rsh server.
    3) On that socket, it sends the remote and local usernames, the
       port number it is listening on (step 1), and the command to run
       on the remote end.
    4) The rsh server "authenticates" that user (by making sure the
       port the client connected from is <1024 and using ~/.rhosts and
       /etc/hosts.equiv) and, if it is allowed, connects back to the
       port the client is listening on.
    5) The client accepts the connection from the server. Anything the
       client receives on this socket is stderr. The client sends
       numbers to the server to send signals. (In other words, "9\n"
       sends SIGKILL on the other end. This assumes that local signal
       numbers and remote signal numbers are the same, which isn't
       really a safe assumption.) The other socket is stdin/stdout.

Note that netcat (nc) can be compiled to do something only a fraction
as evil by defining GAPING_SECURITY_HOLE, if that tells you
anything...  ;-)

> So is FTP error prone? No. Is implementing an FTP server/clients? Yes,
> by observation.

I would disagree.  If a protocol for such a simple task is so
difficult to code properly, it just can't be good.

I see we aren't going to agree on this though, so I'm prepared to drop
the subject.  :-)

> I'm not saying FTP is the best thing since sliced bread. I'm saying your
> statement that FTP is "old and crufty" because it is, well, "old and crufty"
> is quite circular in nature and isn't the objective criticism or opinion 
> you hold it out to be.

Have I claimed to be objective?  Hardly.  I'm just passing on my
experience as both the admin of a somewhat popular FTP server, the
former maintainer of a barely-used ftpd, and the author of a
(different) never-used ftpd.  (To explain that last one, I once
started writing a new ftpd from scratch.  I wrote a *ton* of code,
only to find out that lots of things were much more difficult to
implement that I thought they would be.  Eventually I just hacked the
features I wanted into troll-ftpd.)

> You are enamored with the "shiny new toy" of rsync, methinks.

You are right.  I am.  It is spiffy.

Steve
-- 
steve@silug.org           | Southern Illinois Linux Users Group
(618)398-7360             | See web site for meeting details.
Steven Pritchard          | http://www.silug.org/

-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.