xref: /netbsd-src/libexec/tftpd/tftpd.8 (revision 274254cdae52594c1aa480a736aef78313d15c9c)
1.\"	$NetBSD: tftpd.8,v 1.21 2003/08/07 09:46:53 agc 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 June 11, 2003
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 d
43.Op Fl g Ar group
44.Op Fl l
45.Op Fl n
46.Op Fl s Ar directory
47.Op Fl u Ar user
48.Op Ar directory ...
49.Sh DESCRIPTION
50.Nm
51is a server which supports the
52.Tn DARPA
53Trivial File Transfer Protocol.
54The
55.Tn TFTP
56server operates at the port indicated in the
57.Ql tftp
58service description; see
59.Xr services 5 .
60The server is normally started by
61.Xr inetd 8 .
62.Pp
63The use of
64.Xr tftp 1
65does not require an account or password on the remote system.
66Due to the lack of authentication information,
67.Nm
68will allow only publicly readable files to be accessed.
69Filenames beginning in ``\|\fB.\|.\fP\|/'' or
70containing ``/\|\fB.\|.\fP\|/'' are not allowed.
71Files may be written to only if they already exist and are publicly writable.
72.Pp
73Note that this extends the concept of
74.Qq public
75to include
76all users on all hosts that can be reached through the network;
77this may not be appropriate on all systems, and its implications
78should be considered before enabling tftp service.
79The server should have the user ID with the lowest possible privilege.
80.Pp
81Access to files may be restricted by invoking
82.Nm
83with a list of directories by including up to 20 pathnames
84as server program arguments in
85.Pa /etc/inetd.conf .
86In this case access is restricted to files whose
87names are prefixed by the one of the given directories.
88The given directories are also treated as a search path for
89relative filename requests.
90.Pp
91The options are:
92.Bl -tag -width "directory"
93.It Fl d
94Enable verbose debugging messages to
95.Xr syslogd 8 .
96.It Fl g Ar group
97Change gid to that of
98.Ar group
99on startup.
100If this isn't specified, the gid is set to that of the
101.Ar user
102specified with
103.Fl u .
104.It Fl l
105Logs all requests using
106.Xr syslog 3 .
107.It Fl n
108Suppresses negative acknowledgement of requests for nonexistent
109relative filenames.
110.It Fl s Ar directory
111.Nm
112will
113.Xr chroot 2
114to
115.Ar directory
116on startup.
117This is recommended for security reasons (so that files other than
118those in the
119.Pa /tftpboot
120directory aren't accessible).
121If the remote host passes the directory name as part of the
122file name to transfer, you may have to create a symbolic link
123from
124.Sq tftpboot
125to
126.Sq \&.
127under
128.Pa /tftpboot .
129.It Fl u Ar user
130Change uid to that of
131.Ar user
132on startup.
133If
134.Fl u
135isn't given,
136.Ar user
137defaults to
138.Dq nobody .
139If
140.Fl g
141isn't also given, change the gid to that of
142.Ar user
143as well.
144.El
145.Sh SEE ALSO
146.Xr tftp 1 ,
147.Xr inetd 8
148.Rs
149.%R RFC
150.%N 1350
151.%D July 1992
152.%T "The TFTP Protocol (Revision 2)"
153.Re
154.Rs
155.%R RFC
156.%N 2347
157.%D May 1998
158.%T "TFTP Option Extension"
159.Re
160.Rs
161.%R RFC
162.%N 2348
163.%D May 1998
164.%T "TFTP Blocksize Option"
165.Re
166.Rs
167.%R RFC
168.%N 2349
169.%D May 1998
170.%T "TFTP Timeout Interval and Transfer Size Options"
171.Re
172.Sh HISTORY
173The
174.Nm
175command appeared in
176.Bx 4.2 .
177.Pp
178The
179.Fl s
180flag appeared in
181.Nx 1.0 .
182.Pp
183The
184.Fl g
185and
186.Fl u
187flags appeared in
188.Nx 1.4 .
189.Pp
190IPv6 support was implemented by WIDE/KAME project in 1999.
191.Pp
192TFTP options were implemented by Wasabi Systems, Inc., in 2003,
193and first appeared in
194.Nx 2.0 .
195.Sh BUGS
196Files larger than 33488896 octets (65535 blocks) cannot be transferred
197without client and server supporting blocksize negotiation (RFCs
1982347 and 2348).
199.Pp
200Many tftp clients will not transfer files over 16744448 octets (32767 blocks).
201.Sh SECURITY CONSIDERATIONS
202You are
203.Em strongly
204advised to set up
205.Nm
206using the
207.Fl s
208flag in conjunction with the name of the directory that
209contains the files that
210.Nm
211will serve to remote hosts (e.g.,
212.Pa /tftpboot ) .
213This ensures that only the files that should be served
214to remote hosts can be accessed by them.
215.Pp
216Because there is no user-login or validation within
217the
218.Tn TFTP
219protocol, the remote site will probably have some
220sort of file-access restrictions in place.
221The exact methods are specific to each site and therefore
222difficult to document here.
223