[syslinux] truncated files on write with tftpd-hpa

Alan Sundell asundell+syslinux at fas.harvard.edu
Thu May 1 17:53:26 PDT 2003


On Thu, 1 May 2003, H. Peter Anvin wrote:
> The "connection refused" is probably the best bet for solving this,
> since the natural mutex is the kernel lock on the port number.  This
> would mean we shouldn't open the file until we have connect()ed, which
> is probably correct anyway; if nothing else we still need to send back
> the error code, so we need to connect() no matter what.

Yeah, one face of the problem, as I see it, is that tftpd is writing to
the file (with the O_TRUNC) before the data transfer is really started.

However, if I'm reading the code right, the open() happens well after
the connect().  tftp() is called after connect() in main(), and it's
tftp() that calls validate_access(), which does the truncating.

The way I read it, we're getting the "connection refused" from
recv_time() all the way down in tftp_recvfile() on line 1288 of tftpd.c,
in response to the ACK sent with the send() on line 1282.


Also, with -p/unixperms, isn't open() being used as a permissions check
in validate_access() before sending the ACK?  That's why I was thinking
of doing open() with no O_TRUNC, then doing a truncate before the first
write.  This might simplify things a little by doing the truncate in the
same place whether or not unixperms is set, but it would also mean
treating the first ACK as a special case, which doesn't seem to be the
situation at this point.


Tracking and denying duplicate WRQs came to my mind because the problem
seems similar to the Sorcerer's Apprentice issue, so it might find a
similar solution in the code, but I haven't looked at how you handled
that one.

On the other hand, I can see how this might cause some problems in
situations where a host makes a series of closely-spaced requests using
the same port.  However, the RFC does specifically mention, I think,
that hosts should choose TIDs in a manner that avoids such situations.
(The question is, of course, whether they actually do.)

--Alan



More information about the Syslinux mailing list