<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/libexec, branch stable/10</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>MFC r357223:</title>
<updated>2020-02-04T19:19:48+00:00</updated>
<author>
<name>Dimitry Andric</name>
<email>dim@FreeBSD.org</email>
</author>
<published>2020-02-04T19:19:48+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=564462232a2572d9bedeb4ac887bab56d245c064'/>
<id>564462232a2572d9bedeb4ac887bab56d245c064</id>
<content type='text'>
Merge r357222 from the clang1000-import branch:

Fix the following -Werror warning from clang 10.0.0 in rbootd:

libexec/rbootd/rmpproto.c:335:49: error: multiple unsequenced modifications to 'filename' [-Werror,-Wunsequenced]
        filename = (filename = strrchr(filepath,'/'))? ++filename: filepath;
                 ~                                     ^
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Merge r357222 from the clang1000-import branch:

Fix the following -Werror warning from clang 10.0.0 in rbootd:

libexec/rbootd/rmpproto.c:335:49: error: multiple unsequenced modifications to 'filename' [-Werror,-Wunsequenced]
        filename = (filename = strrchr(filepath,'/'))? ++filename: filepath;
                 ~                                     ^
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r338216:</title>
<updated>2018-10-01T16:11:09+00:00</updated>
<author>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</author>
<published>2018-10-01T16:11:09+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=28b454a277068dc1e68b7cbf9a74bcb31605f1be'/>
<id>28b454a277068dc1e68b7cbf9a74bcb31605f1be</id>
<content type='text'>
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 &lt;rsitze@gmail.com&gt;
Reviewed by:	cem
Differential Revision:	https://reviews.freebsd.org/D16853
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;rsitze@gmail.com&gt;
Reviewed by:	cem
Differential Revision:	https://reviews.freebsd.org/D16853
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r336609:</title>
<updated>2018-10-01T16:09:20+00:00</updated>
<author>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</author>
<published>2018-10-01T16:09:20+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=0f843eba705262256a114818ec5dc2f0529398e9'/>
<id>0f843eba705262256a114818ec5dc2f0529398e9</id>
<content type='text'>
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 =&gt; 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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 =&gt; 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
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r336605:</title>
<updated>2018-10-01T16:08:27+00:00</updated>
<author>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</author>
<published>2018-10-01T16:08:27+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=dc6061b1fc55d388d38c243ff6ad1f9b80887ac0'/>
<id>dc6061b1fc55d388d38c243ff6ad1f9b80887ac0</id>
<content type='text'>
Fix multiple Coverity warnings in tftpd(8)

* Initialize uninitialized variable (CID 1006502)
* strcpy =&gt; 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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix multiple Coverity warnings in tftpd(8)

* Initialize uninitialized variable (CID 1006502)
* strcpy =&gt; 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
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r336587:</title>
<updated>2018-10-01T16:07:32+00:00</updated>
<author>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</author>
<published>2018-10-01T16:07:32+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=41ac23b42a96c6b2bd84e21ccb5a7b918de3a7f8'/>
<id>41ac23b42a96c6b2bd84e21ccb5a7b918de3a7f8</id>
<content type='text'>
tftpd(8): when completing an WRQ, flush the file before acknowleding receipt

tftpd(8) should flush a newly written file to disk before ACKing the final DATA
packet.  Otherwise there is a narrow race window when a subsequent read may not
see the file.  This is somewhat related to r330710, but the race window is much
smaller.  Hopefully this will fix the intermittent tests in Jenkins.

Reported by:	Jenkins
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
tftpd(8): when completing an WRQ, flush the file before acknowleding receipt

tftpd(8) should flush a newly written file to disk before ACKing the final DATA
packet.  Otherwise there is a narrow race window when a subsequent read may not
see the file.  This is somewhat related to r330710, but the race window is much
smaller.  Hopefully this will fix the intermittent tests in Jenkins.

Reported by:	Jenkins
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r330720:</title>
<updated>2018-08-03T14:19:56+00:00</updated>
<author>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</author>
<published>2018-08-03T14:19:56+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=6f8126ebc4fad86fc4cebefdb857a8e0fac07225'/>
<id>6f8126ebc4fad86fc4cebefdb857a8e0fac07225</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r330719:</title>
<updated>2018-08-03T14:19:09+00:00</updated>
<author>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</author>
<published>2018-08-03T14:19:09+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=a358c70defb591a678e00a2ee641f7ce7c0f53d4'/>
<id>a358c70defb591a678e00a2ee641f7ce7c0f53d4</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r330718:</title>
<updated>2018-08-03T14:18:02+00:00</updated>
<author>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</author>
<published>2018-08-03T14:18:02+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=21d1db71f4f29bb309c4af9000f35eab0d1aa227'/>
<id>21d1db71f4f29bb309c4af9000f35eab0d1aa227</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r330710:</title>
<updated>2018-08-03T14:17:11+00:00</updated>
<author>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</author>
<published>2018-08-03T14:17:11+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=b77d00d401c238e4cf773cb5f29ef46eaa21962a'/>
<id>b77d00d401c238e4cf773cb5f29ef46eaa21962a</id>
<content type='text'>
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 &lt;barry_mishler@yahoo.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;barry_mishler@yahoo.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r330696, r330709, r330742, r331358</title>
<updated>2018-08-03T14:13:15+00:00</updated>
<author>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</author>
<published>2018-08-03T14:13:15+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=cbb8e5aaa7b2e299aad31a24d98a0c6a06190a49'/>
<id>cbb8e5aaa7b2e299aad31a24d98a0c6a06190a49</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
</feed>
