Subject: Notes on general oddness...

From: Anders Thulin <[email-masked]>
Date: Thu, 17 Apr 1997 13:30:59 +0200 (MET DST)

Hi!

  Here's some notes jotted down during a recent read-through of the beta-13.
As I don't feel very comfortable with wu-ftp, and don't think I understand
why it does what it does, I hesitate to suggest that these are actual
problems.  They look a bit odd, though, and so may be potential problems.

ftpd.c, retrieve():
  
  The call to dataconn() defines dout and data. fclose(dout) closes dout,
immediately after send_data(), but data isn't reset until just before
the end of the function. It isn't clear why they are separated this way:
it rather tends to make the connection betwen them non-obvious.

ftpd.c, store():

  The closefunc pointer doesn't appear to be useful, as only one assignment
to it ever takes place.

  If fchown() for some reason goes wrong, fdout is not closed. This
is probably not a problem, unless fchown *always* goes wrong -- this would
leave a lot of file descriptors open. (Actually, this is the only
thing I feel fairly sure could be a problem, although only under pretty
weird conditions.)

  Same 'problem' with dataconn and din as in retrieve().

ftpd.c, dataconn():

  Uses 'data' to decide if an existing connection could be used or not.
But data seems to be reset to -1 in all cases, so this code appears to
be non-functional.

  'pdata' seems to be used in a somewhat similar way, but also seems to get
reset to -1 everywhere. See below, though.

extensions.c, newer():

  This seems to be the only place where dataconn() is called, and the file
later fclosed() and data is reset to -1, but pdata *isn't* reset. Deliberate?

Anders Thulin       [email-masked]        013-23 55 32
Telia Engineering AB, Teknikringen 6, S-583 30 Linkoping, Sweden

---

From: Alain Magloire <[email-masked]>
Date: Fri, 18 Apr 1997 16:23:12 -0400 (EDT)

Salut A Vous, O Grand Manitou Anders Thulin !!
>   Here's some notes jotted down during a recent read-through of the beta-13.

...

> it rather tends to make the connection betwen them non-obvious.

agreed, after the fclose(dout) the file descriptor(data/pdata) is close.
I'd say, it's a question of style ?

> ftpd.c, store():
...
> thing I feel fairly sure could be a problem, although only under pretty

not so weird /home/ftp may have been mounted rd_only
or the uid.gid are wrong etc ...

I guess the philosophy behind BSD-ftpd was it's a short
live process spawn by inetd, so no need to be clean.
ftpd is leaking memory all over the place, also.

> But data seems to be reset to -1 in all cases, so this code appears to

This code went to so many patches/enhancement,
They say, when you don't know, it's better to live it alone (i've
learn this the hard way :-)

Somewhere in the rfc, it says that the client can use the previous
data port if no PORT/PASV command is issued, of course
nobody uses that because of TIME_WAIT and EOF will close the con.
This was discourage later in an other rfc 112x something.

> later fclosed() and data is reset to -1, but pdata *isn't* reset. Deliberate?

It's one of those questionnable extensions :-)
I suppose the author didn't foresee that Web browser would
have make the PASV mode so popular :-)

I agree with you, if the client always uses PASV mode
for the data transfer then pdata should have been reset to -1.

It may be a problem but it's very hard to know, must
clients are very well behave and reissue a PASV or PORT
before any data exchange.

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!