<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
  "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
<!-- conversion to man: 
  xsltproc  /usr/apps/docbook/xsl/1.67.2/manpages/docbook.xsl tftpd.8.dbk
-->
<refentry id="tftpd">
    <refentryinfo>
        <productname>Linux</productname>
        <title>System Administration</title>
        <date>27 September 2002</date>
    </refentryinfo>
	<refmeta>
		<refentrytitle>tftpd</refentrytitle>
		<manvolnum>8</manvolnum>
	</refmeta>
	<refnamediv>
		<refname>tftpd</refname>
		<refpurpose>Trivial File Transfer Protocol server</refpurpose>
	</refnamediv>
	<refsynopsisdiv>
		<cmdsynopsis>
			<command>tftpd</command>
			<arg choice="plain"><replaceable>directory</replaceable></arg>
		</cmdsynopsis>
	</refsynopsisdiv>
	
	<refsection>
		
		<title>DESCRIPTION</title>
		
<para><command>tftpd</command> is a server which supports the DARPA 
Trivial File Transfer Protocol (<ulink
url="ftp://ftp.isi.edu/in-notes/rfc1350.txt">RFC1350</ulink>).
The TFTP server is started by <citerefentry>
	<refentrytitle>inetd</refentrytitle>
	<manvolnum>8</manvolnum>
</citerefentry>.</para>

<para><replaceable>directory</replaceable> is required argument; if it is 
not given <command>tftpd</command> aborts. This path is prepended to any
file name requested via TFTP protocol, effectively chrooting
<command>tftpd</command> to this directory. File names are
validated not to escape out of this directory, however
administrator may configure such escape using symbolic links.</para>

<para>It is in difference of variants of <command>tftpd</command> 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.</para>

<para>In the case when <command>tftpd</command> is used together 
with <citerefentry>
	<refentrytitle>rarpd</refentrytitle>
	<manvolnum>8</manvolnum>
</citerefentry>, 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 
<citerefentry>
	<refentrytitle>rarpd</refentrytitle>
	<manvolnum>8</manvolnum>
</citerefentry> for more details.</para>
	</refsection>
	
	<refsection>
		
		<title>SECURITY</title>
		
<para>TFTP protocol does not provide any authentication. Due to this
capital flaw <command>tftpd</command> 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.</para>

<para>Impact is evident, directory exported via 
TFTP <emphasis>must not</emphasis> 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</emphasis> passwords and may
contain some information about the network, which you were
not going to make public.</para>

<para>The <command>tftpd</command> server should be executed 
by <command>inetd</command> 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</command> 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.</para>
	</refsection>
	
	<refsection>
		
		<title>SEE ALSO</title>
		
<para><citerefentry>
	<refentrytitle>rarpd</refentrytitle>
	<manvolnum>8</manvolnum>
</citerefentry>, <citerefentry>
	<refentrytitle>tftp</refentrytitle>
	<manvolnum>1</manvolnum>
</citerefentry>, <citerefentry>
	<refentrytitle>inetd</refentrytitle>
	<manvolnum>8</manvolnum>
</citerefentry>.</para>
	</refsection>
	
	<refsection>
		
		<title>HISTORY</title>
		
<para>The <command>tftpd</command> command appeared in 4.2BSD. The source 
in iputils is cleaned up both syntactically (ANSIized) and
semantically (UDP socket IO).</para>

<para>It is distributed with iputils mostly as good demo of an
interesting feature (<constant>MSG_CONFIRM</constant>) 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.</para>
	</refsection>
	
	<refsection>
		
		<title>AVAILABILITY</title>
		
<para><command>tftpd</command> is part 
of <application>iputils</application> package and the latest
versions are available in source form for anonymous via <ulink
url="ftp://ftp.inr.ac.ru/ip-routing/iputils-current.tar.gz"/>.</para>
	</refsection>
</refentry>

