blob: fe7fd7c5e0d5f3aa86a6bfdb6d943d31d14c2f7b [file] [log] [blame]
<refentry id="tftpd">
<refpurpose>Trivial File Transfer Protocol server</refpurpose>
<arg choice="req"><replaceable/directory/</arg>
<command/tftpd/ is a server which supports the DARPA
Trivial File Transfer Protocol
(<ulink url="">RFC1350</ulink>).
The TFTP server is started
by <citerefentry><refentrytitle/inetd/<manvolnum/8/</citerefentry>.
<replaceable/directory/ is required argument; if it is not given
<command/tftpd/ aborts. This path is prepended to any file name requested
via TFTP protocol, effectively chrooting <command/tftpd/ to this directory.
File names are validated not to escape out of this directory, however
administrator may configure such escape using symbolic links.
It is in difference of variants of <command/tftpd/ usually distributed
with unix-like systems, which take a list of directories and match
file names to start from one of given prefixes or to some random
default, when no arguments were given. There are two reasons not to
behave in this way: first, it is inconvenient, clients are not expected
to know something about layout of filesystem on server host.
And second, TFTP protocol is not a tool for browsing of server's filesystem,
it is just an agent allowing to boot dumb clients.
In the case when <command/tftpd/ is used together with
<link linkend="rarpd">
tftp directories in these services should coincide and it is expected
that each client booted via TFTP has boot image corresponding
its IP address with an architecture suffix following Sun Microsystems
conventions. See
<link linkend="rarpd">
for more details.
TFTP protocol does not provide any authentication.
Due to this capital flaw <command/tftpd/ is not able to restrict
access to files and will allow only publically readable
files to be accessed. Files may be written only if they already
exist and are publically writable.
Impact is evident, directory exported via TFTP <emphasis/must not/
contain sensitive information of any kind, everyone is allowed
to read it as soon as a client is allowed. Boot images do not contain
such information as rule, however you should think twice before
publishing f.e. Cisco IOS config files via TFTP, they contain
<emphasis/unencrypted/ passwords and may contain some information
about the network, which you were not going to make public.
The <command/tftpd/ server should be executed by <command/inetd/
with dropped root privileges, namely with a user ID giving minimal
access to files published in tftp directory. If it is executed
as superuser occasionally, <command/tftpd/ drops its UID and GID
to 65534, which is most likely not the thing which you expect.
However, this is not very essential; remember, only files accessible
for everyone can be read or written via TFTP.
<refsect1><title>SEE ALSO</title>
<link linkend="rarpd">
The <command/tftpd/ command appeared in 4.2BSD. The source in iputils
is cleaned up both syntactically (ANSIized) and semantically (UDP socket IO).
It is distributed with iputils mostly as good demo of an interesting feature
(<constant/MSG_CONFIRM/) allowing to boot long images by dumb clients
not answering ARP requests until they are finally booted.
However, this is full functional and can be used in production.
<command/tftpd/ is part of <filename/iputils/ package
and the latest versions are available in source form at
<ulink url=""></ulink>.
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License Version 2.
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
See the GNU General Public License for more details.
For more details see the file COPYING in the source
distribution of Linux kernel of version 2.4.