1.\" $NetBSD: tftpd.8,v 1.16 2002/01/15 02:28:41 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. 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.Sh HISTORY 159The 160.Nm 161command appeared in 162.Bx 4.2 . 163.Pp 164The 165.Fl s 166flag appeared in 167.Nx 1.0 . 168.Pp 169The 170.Fl g 171and 172.Fl u 173flags appeared in 174.Nx 1.4 . 175.Pp 176IPv6 support was implemented by WIDE/KAME project in 1999. 177.Sh BUGS 178Files larger than 33488896 octets (65535 blocks) cannot be transferred 179without client and server supporting blocksize negotiation (RFC1783). 180.Pp 181Many tftp clients will not transfer files over 16744448 octets (32767 blocks). 182.Sh SECURITY CONSIDERATIONS 183You are 184.Em strongly 185advised to setup 186.Nm 187using the 188.Fl s 189flag in conjunction with the name of the directory that 190contains the files that 191.Nm 192will serve to remote hosts (e.g., 193.Pa /tftpboot ) . 194This ensures that only the files that should be served 195to remote hosts can be accessed by them. 196.Pp 197Because there is no user-login or validation within 198the 199.Tn TFTP 200protocol, the remote site will probably have some 201sort of file-access restrictions in place. 202The exact methods are specific to each site and therefore 203difficult to document here. 204