Radix cross Linux

<refentry xmlns:db="http://docbook.org/ns/docbook" version="5.0"
xml:id="man.tftpd">

  <refentryinfo>
    <title>tftpd</title>
    <productname>iputils</productname>
  </refentryinfo>

  <refmeta>
    <refentrytitle>
      <application>tftpd</application>
    </refentrytitle>
    <manvolnum>8</manvolnum>
    <refmiscinfo class='manual'>iputils</refmiscinfo>
  </refmeta>

  <refnamediv>
    <refname>tftpd</refname>
    <refpurpose>Trivial File Transfer Protocol server</refpurpose>
  </refnamediv>

  <refsynopsisdiv xml:id="synopsis">
    <cmdsynopsis>
      <command>tftpd</command>
      <arg choice="opt" rep="norepeat">-V</arg>
      <arg choice="plain" rep="norepeat">
        <replaceable>directory</replaceable>
      </arg>
      <sbr />
    </cmdsynopsis>
  </refsynopsisdiv>

  <refsection xml:id="description">
    <info>
      <title>DESCRIPTION</title>
    </info>
    <para>
    <command>tftpd</command> is a server which supports the DARPA
    Trivial File Transfer Protocol (RFC1350). The TFTP server is
    started by
    <citerefentry>
      <refentrytitle>inetd</refentrytitle>
      <manvolnum>8</manvolnum>
    </citerefentry>.</para>
    <para>
    <emphasis remap="I">directory</emphasis> 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 xml:id="security">
    <info>
      <title>SECURITY</title>
    </info>
    <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 publicly readable files to be accessed.
    Files may be written only if they already exist and are
    publicly writable.</para>
    <para>Impact is evident, directory exported via TFTP
    <emphasis remap="B">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 remap="B">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
    <emphasis remap="B">inetd</emphasis> 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 xml:id="see_also">
    <info>
      <title>SEE ALSO</title>
    </info>
    <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 xml:id="history">
    <info>
      <title>HISTORY</title>
    </info>
    <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 (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.</para>
  </refsection>

  <refsection xml:id="availability">
    <info>
      <title>AVAILABILITY</title>
    </info>
    <para>
    <command>tftpd</command> is part of
    <emphasis remap="I">iputils</emphasis> package.</para>
  </refsection>
</refentry>