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