1.\" $NetBSD: tftpd.8,v 1.31 2019/01/09 17:19:08 uwe Exp $ 2.\" 3.\" Copyright (c) 1983, 1991, 1993 4.\" The Regents of the University of California. All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that the following conditions 8.\" are met: 9.\" 1. Redistributions of source code must retain the above copyright 10.\" notice, this list of conditions and the following disclaimer. 11.\" 2. Redistributions in binary form must reproduce the above copyright 12.\" notice, this list of conditions and the following disclaimer in the 13.\" documentation and/or other materials provided with the distribution. 14.\" 3. Neither the name of the University nor the names of its contributors 15.\" may be used to endorse or promote products derived from this software 16.\" without specific prior written permission. 17.\" 18.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 19.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 20.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 21.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 22.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 23.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 24.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 25.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 26.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 27.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 28.\" SUCH DAMAGE. 29.\" 30.\" from: @(#)tftpd.8 8.1 (Berkeley) 6/4/93 31.\" 32.Dd May 5, 2015 33.Dt TFTPD 8 34.Os 35.Sh NAME 36.Nm tftpd 37.Nd 38.Tn DARPA 39Internet Trivial File Transfer Protocol server 40.Sh SYNOPSIS 41.Nm 42.Op Fl bcdln 43.Op Fl g Ar group 44.Op Fl p Ar pathsep 45.Op Fl s Ar directory 46.Op Fl u Ar user 47.Op Ar directory ... 48.Sh DESCRIPTION 49.Nm 50is a server which supports the 51.Tn DARPA 52Trivial File Transfer Protocol. 53The 54.Tn TFTP 55server operates at the port indicated in the 56.Ql tftp 57service description; see 58.Xr services 5 . 59The server is normally started by 60.Xr inetd 8 . 61.Pp 62The use of 63.Xr tftp 1 64does not require an account or password on the remote system. 65Due to the lack of authentication information, 66.Nm 67will allow only publicly readable files to be accessed. 68Filenames beginning in 69.Dq Pa ../ 70or containing 71.Dq Pa /../ 72are not allowed. 73Unless 74.Fl c 75is used, 76files may be written to only if they already exist and are publicly writable. 77.Pp 78Note that this extends the concept of 79.Qq public 80to include 81all users on all hosts that can be reached through the network; 82this may not be appropriate on all systems, and its implications 83should be considered before enabling tftp service. 84The server should have the user ID with the lowest possible privilege. 85.Pp 86Access to files may be restricted by invoking 87.Nm 88with a list of directories by including up to 20 pathnames 89as server program arguments in 90.Pa /etc/inetd.conf . 91In this case access is restricted to files whose 92names are prefixed by the one of the given directories. 93The given directories are also treated as a search path for 94relative filename requests. 95.Pp 96The options are: 97.Bl -tag -width "XsXdirectoryX" 98.It Fl b 99Allow clients which return acknowledgements to the broadcast address to 100communicate with the tftp server. 101Some tftp clients, notably ones resident in the ROMs of older Cisco 102equipment, return their acknowledgements to the broadcast address rather 103than the server's unicast address. 104.It Fl c 105Allow unrestricted creation of new files. 106Without this flag, only existing publicly writable files can be overwritten. 107.It Fl d 108Enable verbose debugging messages to 109.Xr syslogd 8 . 110.It Fl g Ar group 111Change gid to that of 112.Ar group 113on startup. 114If this isn't specified, the gid is set to that of the 115.Ar user 116specified with 117.Fl u . 118.It Fl l 119Logs all requests using 120.Xr syslog 3 . 121.It Fl n 122Suppresses negative acknowledgement of requests for nonexistent 123relative filenames. 124.It Fl p Ar pathsep 125All occurrences of the single character 126.Ar pathsep 127(path separator) in the requested filename are replaced with 128.Sq / . 129.It Fl s Ar directory 130.Nm 131will 132.Xr chroot 2 133to 134.Ar directory 135on startup. 136This is recommended for security reasons (so that files other than 137those in the 138.Pa /tftpboot 139directory aren't accessible). 140If the remote host passes the directory name as part of the 141file name to transfer, you may have to create a symbolic link 142from 143.Sq tftpboot 144to 145.Sq \&. 146under 147.Pa /tftpboot . 148.It Fl u Ar user 149Change uid to that of 150.Ar user 151on startup. 152If 153.Fl u 154isn't given, 155.Ar user 156defaults to 157.Dq nobody . 158If 159.Fl g 160isn't also given, change the gid to that of 161.Ar user 162as well. 163.El 164.Sh SEE ALSO 165.Xr tftp 1 , 166.Xr inetd 8 167.Rs 168.%R RFC 169.%N 1350 170.%D July 1992 171.%T "The TFTP Protocol (Revision 2)" 172.Re 173.Rs 174.%R RFC 175.%N 2347 176.%D May 1998 177.%T "TFTP Option Extension" 178.Re 179.Rs 180.%R RFC 181.%N 2348 182.%D May 1998 183.%T "TFTP Blocksize Option" 184.Re 185.Rs 186.%R RFC 187.%N 2349 188.%D May 1998 189.%T "TFTP Timeout Interval and Transfer Size Options" 190.Re 191.Sh HISTORY 192The 193.Nm 194command appeared in 195.Bx 4.2 . 196.Pp 197The 198.Fl s 199flag appeared in 200.Nx 1.0 . 201.Pp 202The 203.Fl g 204and 205.Fl u 206flags appeared in 207.Nx 1.4 . 208.Pp 209IPv6 support was implemented by WIDE/KAME project in 1999. 210.Pp 211TFTP options were implemented by Wasabi Systems, Inc., in 2003, 212and first appeared in 213.Nx 2.0 . 214.Sh BUGS 215Files larger than 33,553,919 octets (65535 blocks, last one less than 512 216octets) cannot be correctly transferred without client and server 217supporting blocksize negotiation (RFCs 2347 and 2348). 218As a kludge, 219.Nm 220accepts a sequence of block numbers which wrap to zero after 65535. 221.Pp 222Many tftp clients will not transfer files over 16,776,703 octets 223(32767 blocks), as they incorrectly count the block number using 224a signed rather than unsigned 16-bit integer. 225.Sh SECURITY CONSIDERATIONS 226You are 227.Em strongly 228advised to set up 229.Nm 230using the 231.Fl s 232flag in conjunction with the name of the directory that 233contains the files that 234.Nm 235will serve to remote hosts (e.g., 236.Pa /tftpboot ) . 237This ensures that only the files that should be served 238to remote hosts can be accessed by them. 239.Pp 240Because there is no user-login or validation within 241the 242.Tn TFTP 243protocol, the remote site will probably have some 244sort of file-access restrictions in place. 245The exact methods are specific to each site and therefore 246difficult to document here. 247.Pp 248If unrestricted file upload is enabled via the 249.Fl c 250option, care should be taken that this can be used 251to fill up disk space in an uncontrolled manner 252if this is used in an insecure environment. 253