1.\" $NetBSD: tftpd.8,v 1.28 2010/04/29 21:34:04 wiz 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 April 22, 2010 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 cdln 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 c 99Allow unrestricted creation of new files. 100Without this flag, only existing publicly writable files can be overwritten. 101.It Fl d 102Enable verbose debugging messages to 103.Xr syslogd 8 . 104.It Fl g Ar group 105Change gid to that of 106.Ar group 107on startup. 108If this isn't specified, the gid is set to that of the 109.Ar user 110specified with 111.Fl u . 112.It Fl l 113Logs all requests using 114.Xr syslog 3 . 115.It Fl n 116Suppresses negative acknowledgement of requests for nonexistent 117relative filenames. 118.It Fl p Ar pathsep 119All occurances of the single character 120.Ar pathsep 121(path separator) in the requested filename are replaced with 122.Sq / . 123.It Fl s Ar directory 124.Nm 125will 126.Xr chroot 2 127to 128.Ar directory 129on startup. 130This is recommended for security reasons (so that files other than 131those in the 132.Pa /tftpboot 133directory aren't accessible). 134If the remote host passes the directory name as part of the 135file name to transfer, you may have to create a symbolic link 136from 137.Sq tftpboot 138to 139.Sq \&. 140under 141.Pa /tftpboot . 142.It Fl u Ar user 143Change uid to that of 144.Ar user 145on startup. 146If 147.Fl u 148isn't given, 149.Ar user 150defaults to 151.Dq nobody . 152If 153.Fl g 154isn't also given, change the gid to that of 155.Ar user 156as well. 157.El 158.Sh SEE ALSO 159.Xr tftp 1 , 160.Xr inetd 8 161.Rs 162.%R RFC 163.%N 1350 164.%D July 1992 165.%T "The TFTP Protocol (Revision 2)" 166.Re 167.Rs 168.%R RFC 169.%N 2347 170.%D May 1998 171.%T "TFTP Option Extension" 172.Re 173.Rs 174.%R RFC 175.%N 2348 176.%D May 1998 177.%T "TFTP Blocksize Option" 178.Re 179.Rs 180.%R RFC 181.%N 2349 182.%D May 1998 183.%T "TFTP Timeout Interval and Transfer Size Options" 184.Re 185.Sh HISTORY 186The 187.Nm 188command appeared in 189.Bx 4.2 . 190.Pp 191The 192.Fl s 193flag appeared in 194.Nx 1.0 . 195.Pp 196The 197.Fl g 198and 199.Fl u 200flags appeared in 201.Nx 1.4 . 202.Pp 203IPv6 support was implemented by WIDE/KAME project in 1999. 204.Pp 205TFTP options were implemented by Wasabi Systems, Inc., in 2003, 206and first appeared in 207.Nx 2.0 . 208.Sh BUGS 209Files larger than 33,553,919 octets (65535 blocks, last one less than 512 210octets) cannot be correctly transferred without client and server 211supporting blocksize negotiation (RFCs 2347 and 2348). 212As a kludge, 213.Nm 214accepts a sequence of block numbers which wrap to zero after 65535. 215.Pp 216Many tftp clients will not transfer files over 16,776,703 octets 217(32767 blocks), as they incorrectly count the block number using 218a signed rather than unsigned 16-bit integer. 219.Sh SECURITY CONSIDERATIONS 220You are 221.Em strongly 222advised to set up 223.Nm 224using the 225.Fl s 226flag in conjunction with the name of the directory that 227contains the files that 228.Nm 229will serve to remote hosts (e.g., 230.Pa /tftpboot ) . 231This ensures that only the files that should be served 232to remote hosts can be accessed by them. 233.Pp 234Because there is no user-login or validation within 235the 236.Tn TFTP 237protocol, the remote site will probably have some 238sort of file-access restrictions in place. 239The exact methods are specific to each site and therefore 240difficult to document here. 241.Pp 242If unrestricted file upload is enabled via the 243.Fl c 244option, care should be taken that this can be used 245to fill up disk space in an uncontrolled manner 246if this is used in an insecure environment. 247