The use of tftp(1) does not require an account or password on the remote system. Due to the lack of authentication information, tftpd will allow only publicly readable files to be accessed. Filenames beginning in ``..../'' or containing ``/..../'' are not allowed. Files may be written to only if they already exist and are publicly writable.
Note that this extends the concept of "public to include all users on all hosts that can be reached through the network; this may not be appropriate on all systems, and its implications should be considered before enabling tftp service. The server should have the user ID with the lowest possible privilege.
Access to files may be restricted by invoking
tftpd
with a list of directories by including up to 20 pathnames
as server program arguments in
/etc/inetd.conf
.
In this case access is restricted to files whose
names are prefixed by the one of the given directories.
The given directories are also treated as a search path for
relative filename requests.
The options are:
/tftpboot
directory aren't accessible).
If the remote host passes the directory name as part of the
file name to transfer, you may have to create a symbolic link
from
`tftpboot'
to
`.'
under
/tftpboot
.
The -s flag appeared in NetBSD1.0.
The -g and -u flags appeared in NetBSD1.4.
IPv6 support was implemented by WIDE/KAME project in 1999.
TFTP options were implemented by Wasabi Systems, Inc., in 2003, and first appeared in NetBSD2.0.
Many tftp clients will not transfer files over 16744448 octets (32767 blocks).
/tftpboot
).
This ensures that only the files that should be served
to remote hosts can be accessed by them.
Because there is no user-login or validation within the TFTP protocol, the remote site will probably have some sort of file-access restrictions in place. The exact methods are specific to each site and therefore difficult to document here.