345389 |
21-Mar-2019 |
asomers |
MFC r336609:
Fix several Coverity warnings in tftp
Some of the changes are in the libexec/tftpd directory, but to functions that are only used by tftp(1) (they share some code).
* strcpy => strlcpy (1006793, 1006794, 1006796, 1006741) * Unchecked return value and TOCTTOU (1009314) * NULL pointer dereference (1018035, 1018036)
Reported by: Coverity CID: 1006793, 1006794, 1006796, 1006741, 1009314, 1018035 CID: 1018036 |
339057 |
01-Oct-2018 |
asomers |
MFC r338216:
tftpd: Fix data corruption bug with netascii
Transferring files in netascii format requires, among other things, translating all CR characters to a CR,NUL pair. tftpd does this correctly except when the CR occurs as the last octet of a packet. In that case, it erroneously drops the NUL which should be part of the following packet. The bug was caused by using 0 as a sentinel value in a variable that could legitimately hold 0. Fix it by switching the sentinel value to -1.
PR: 178055 Reported by: Richard <rsitze@gmail.com> Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D16853 |
339051 |
01-Oct-2018 |
asomers |
MFC r336605:
Fix multiple Coverity warnings in tftpd(8)
* Initialize uninitialized variable (CID 1006502) * strcpy => strlcpy (CID 1006792, 1006791, 1006790) * Check function return values (CID 1009442, 1009441, 1009440) * Delete dead code in receive_packet (not reported by Coverity) * Remove redundant alarm(3) in receive_packet (not reported by Coverity)
Reported by: Coverity CID: 1006502, 1006792, 1006791, 1006790, 1009442, 1009441, 1009440 Differential Revision: https://reviews.freebsd.org/D11287 |
332609 |
16-Apr-2018 |
asomers |
MFC r330710, r330718-r330720
r330710: tftpd: Flush files as soon as they are fully received
On an RRQ, tftpd doesn't exit as soon as it's finished receiving a file. Instead, it waits five seconds just in case the client didn't receive the server's last ACK and decides to resend the final DATA packet. Unfortunately, this created a 5 second delay from when the client thinks it's done sending the file, and when the file is available for other processes.
Fix this bug by closing the file as soon as receipt is finished.
PR: 157700 Reported by: Barry Mishler <barry_mishler@yahoo.com>
r330718: tftpd: Verify world-writability for WRQ when using relative paths
tftpd(8) says that files may only be written if they already exist and are publicly writable. tftpd.c verifies that a file is publicly writable if it uses an absolute pathname. However, if the pathname is relative, that check is skipped. Fix it.
Note that this is not a security vulnerability, because the transfer ultimately doesn't work unless the file already exists and is owned by user nobody. Also, this bug does not affect the default configuration, because the default uses the "-s" option which makes all pathnames absolute.
PR: 226004
r330719: tftpd: Abort on an WRQ access violation
On a WRQ (write request) tftpd checks whether the client has access permission for the file in question. If not, then the write is prevented. However, tftpd doesn't reply with an ERROR packet, nor does it abort. Instead, it tries to receive the packet anyway.
The symptom is slightly different depending on the nature of the error. If the target file is nonexistent and tftpd lacks permission to create it, then tftpd will willingly receive the file, but not write it anywhere. If the file exists but is not writable, then tftpd will fail to ACK to WRQ.
PR: 225996
r330720: tftpd: reject unknown opcodes
If tftpd receives a command with an unknown opcode, it simply exits 1. It doesn't send an ERROR packet, and the client will hang waiting for one. Fix it.
PR: 226005 |
332608 |
16-Apr-2018 |
asomers |
MFC r330696, r330709, r330742, r331358
r330696: Add some functional tests for tftpd(8)
tftpd(8) is difficult to test in isolation due to its relationship with inetd. Create a test program that mimics the behavior of tftp(1) and inetd(8) and verifies tftpd's response in several different scenarios.
These test cases cover all of the basic TFTP protocol, but not the optional parts.
PR: 157700 PR: 225996 PR: 226004 PR: 226005 Differential Revision: https://reviews.freebsd.org/D14310
r330709: Commit missing file from r330696
X-MFC-With: 330696
r330742: tftpd: fix the build of tests on i386 after 330696
It's those darn printf format specifiers again
Reported by: cy, kibab X-MFC-With: 330696
r331358: tftpd: misc Coverity cleanup in the tests
A bunch of unchecked return values from open(2) and read(2)
Reported by: Coverity CID: 1386900, 1386911, 1386926, 1386928, 1386932, 1386942 CID: 1386961, 1386979 X-MFC-With: 330696 |
241848 |
22-Oct-2012 |
eadler |
Check the return error of set[e][ug]id. While this can never fail in the current version of FreeBSD, this isn't guarenteed by the API. Custom security modules, or future implementations of the setuid and setgid may fail.
Submitted by: Erik Cederstrand Approved by: cperciva MFC after: 3 days
|
241720 |
19-Oct-2012 |
ed |
Fix warnings found by -Wmising-variable-declarations.
This self-written compiler warning, which is hopefully going to be committed into LLVM sources soon, warns about potentially missing `static' keywords, similar to -Wmissing-prototypes.
- bin/pax: Move external declaration of chdname and s_mask into extern.h. - bin/setfacl: Move setfacl.c-specific stuff out of setfacl.h. - sbin/mount_fusefs: Remove char *progname; use getprogname(). - others: add `static' where possible.
|
231973 |
21-Feb-2012 |
emaste |
Avoid error log for transfer stop w/o error code.
A number of tftp clients, including the one in Intel's pxe boot loader, may intentionally stop a transfer using error code 0 (i.e., EUNDEF). These are not real errors. Avoid spamming log files with these by logging them at level LOG_DEBUG instead.
Discussed on -hackers with an initial patch proposal; this change is an improved approach suggested by kan@.
|
224537 |
31-Jul-2011 |
rodrigc |
Pull in some wording to the tftpd.8 man page from NetBSD, with some slight changes:
========================================================================================= http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/tftpd/tftpd.8?only_with_tag=MAIN#rev1.22
Revision 1.22 or diffs], Fri Jan 8 21:05:14 2010 UTC (18 months, 2 weeks ago) by christos
Patrick Welche <prlw1@cam.ac.uk> - add -p pathsep option - make wrap to zero work, but produce a warning While here: - fix gcc warnings, in particular variable clobbered warnings (compiling with fewer warnings does not really fix the problem) =========================================================================================
These wording changes clarify the default rollover behavior as a "kludge". Also, the block numbers and octet counts for 65535 blocks and 32767 blocks are more accurate than the existing documented numbers.
Requested by: Pawan Gupta <pawang at juniper dot net> Obtained from: Juniper Networks Approved by: re (kib)
|
224536 |
31-Jul-2011 |
rodrigc |
In the old TFTP server, there was an undocumented behavior where the block counter would rollover to 0 if a file larger than 65535 blocks was transferred. With the default block size of 512 octets per block, this is a file size of approximately 32 megabytes.
The new TFTP server code would report an error and stop transferring the file if a file was larger than 65535 blocks.
This patch restores the old TFTP server's behavior to the new TFTP server code. If a TFTP client transfers a file larger than 65535 blocks, and does *not* specify the "rollover" option, then automatically rollover the block counter to 0 every time we reach 65535 blocks.
This restores interoperability with the FreeBSD 6 TFTP client. Without this change, if a FreeBSD 6 TFTP client tried to retrieve a file larger than 65535 blocks from a FreeBSD 9 TFTP server , the transfer would fail. The same file could be retrieved successfully if the same FreeBSD 6 TFTP client was used against a FreeBSD 6 TFTP server.
Approved by: re (kib) Tested by: Pawan Gupta <pawang at juniper dot net>, Obtained from: Juniper Networks
|
223487 |
24-Jun-2011 |
rodrigc |
Bring back synchnet() implementation from older tftp implementation. The synchnet() function was converted to a no-op when the new TFTP implementation was committed to FreeBSD. However, this function, as it was in the older code, is needed in order to synchronize between the tftpd server and tftp clients, which may be buggy.
Specifically, we had a buggy TFTP client which would send TFTP ACK packets for non-TFTP packets, which would cause the count of packets to get out of whack, causing transfers to fail with the new TFTPD implementation.
Obtained from: Juniper Networks Submitted by: Santhanakrishnan Balraj <sbalraj at juniper dot net>
|
213102 |
24-Sep-2010 |
marius |
Remove the duplicate logging of failed read requests, whose error message also was inappropriate as it triggered for every EACCESS and ENOTFOUND, not just the case the -n option is intended to deal with and thus really spammed us with ~20 messages in the default configuration when booting a diskless FreeBSD client, introduced with r207608 again.
MFC after: 1 week
|
207608 |
04-May-2010 |
imp |
Go ahead and merge the work edwin@ on tftpd into the tree. It is a lot better than what's in the tree now. Edwin tested it at a prior employer, but can't test it today. I've found that it works a lot better with the various uboot versions that I've used in my embedded work. Here's the pkg-descr from the port that describes the changes:
It all started when we got some new routers, which told me the following when trying to upload configuration or download images from it: The TFTP server doesn't support the blocksize option.
My curiousity was triggered, it took me some reading of RFCs and other documentation to find out what was possible and what could be done. Was plain TFTP very simple in its handshake, TFTP with options was kind of messy because of its backwards capability: The first packet returned could either be an acknowledgement of options, or the first data packet.
Going through the source code of src/libexec/tftpd and going through the code of src/usr.bin/tftp showed that there was a lot of duplicate code, and the addition of options would only increase the amount of duplicate code. After all, both the client and the server can act as a sender and receiver.
At the end, it ended up with a nearly complete rewrite of the tftp client and server. It has been tested against the following TFTP clients and servers:
- Itself (yay!) - The standard FreeBSD tftp client and server - The Fedora Core 6 tftp client and server - Cisco router tftp client - Extreme Networks tftp client
It supports the following RFCs:
RFC1350 - THE TFTP PROTOCOL (REVISION 2) RFC2347 - TFTP Option Extension RFC2348 - TFTP Blocksize Option RFC2349 - TFTP Timeout Interval and Transfer Size Options RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)
It supports the following unofficial TFTP Options as described at http://www.compuphase.com/tftp.htm:
blksize2 - Block size restricted to powers of 2, excluding protocol headers rollover - Block counter roll-over (roll back to zero or to one)
From the tftp program point of view the following things are changed:
- New commands: "blocksize", "blocksize2", "rollover" and "options" - Development features: "debug" and "packetdrop"
If you try this tftp/tftpd implementation, please let me know if it works (or doesn't work) and against which implementaion so I can get a list of confirmed working systems.
Author: Edwin Groothuis <edwin@FreeBSD.org>
|
201380 |
02-Jan-2010 |
ed |
Make WARNS=6 the default for libexec/.
Just like bin/ and sbin/, I think setting WARNS to the highest value possible will make it more attractive for people to fix warnings.
- The WARNS variable is set in the Makefile in the directory of the application itself, making it more likely that it will be removed out of curiosity to see what happens. - New applications will most likely build with WARNS=6 out of the box, because the author would more likely fix the warnings during development than lower WARNS.
Unfortunately almost all apps in libexec require a lowered value of WARNS.
|
173852 |
23-Nov-2007 |
edwin |
Add the -W options, which acts the same as -w but will generate unique names based on the submitted filename, a strftime(3) format string and a two digit sequence number.
By default the strftime(3) format string is %Y%m%d (YYYYMMDD), but this can be changed by the -F option.
PR: bin/106049 (based on patch in that PR) Approved by: grog@ (mentor)
|
129680 |
24-May-2004 |
mdodd |
Add two new flags: -w, which allows new files to be created, and -U, which allows the umask to be set.
Obtained from: Patton Electronics, Co.
|
112452 |
20-Mar-2003 |
dwmalone |
Clean up some warnings that don't result in a change in the object file: Constness, missing prototypes, non-ansi prototypes, missing initialisers, unnecessary declarations, shadowing.
Reviewed by: md5
|
21673 |
14-Jan-1997 |
jkh |
Make the long-awaited change from $Id$ to $FreeBSD$
This will make a number of things easier in the future, as well as (finally!) avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been insane otherwise.
|
18458 |
22-Sep-1996 |
imp |
Reviewed by: Bill Fenner <fennder@parc.xerox.com> Reviewed by: Garrett Wollman <wollman@freebsd.org> Submitted by: Warner Losh <imp@village.org> Close PR bin/1145: Add -s flag to tftpd. This enables the so-called secure mode of tftpd where it chroots to a given directory before allowing access to the files. In addition, it runs as nobody when in this mode. Reviewed a long time ago by Bill and Garrett. Apply my patch from the pr, and close the PR.
|