utftpd(8)utftpd(8)NAMEutftpd - a trivial file transfer protocol (TFTP) server
SYNOPSIS
utftp [options] [dirs]
DESCRIPTIONutftpd sends and receives files with the TFTP protocol. It is normally
started from inetd.
TFTP doesn't support authentication, so the only way to authenticate
TFTP clients is by using IP addresses.
traditional TFTP access control
In traditional mode utftpd will allow access to files in all
directories (and subdirectories of those) named one the command
line. Read access will be allowed for all publicly readable
files and write access to already existing and publicy writable
files. Unlike other TFTP servers utftpd will deny all access if
no directories have been specified on the command line. If you
wish to sacrifice all security you can still specify a single
slash character.
traditional mode access control summary
This means that every host which can talk to the TFTP server can
read and write all those files, and of course every user on that
hosts can do that, too. Therefore you should protect those TFTP
servers with tcpd or a packet filter.
There is no client-specific access control in this mode: all
clients get the same rights.
relative filenames in traditional mode
are allowed for read accesses only. If utftpd sees a relative
file name it qualifies it with a eventual value of the --global-
chdir option, if any, and then tries to find the file in any of
the directories named on the command line. It will stop at the
first file. If that happens to be unreadable it will deny
access.
extended access control
utftpd also offers a more elaborate access control scheme, which
will be used if the --config-file option is given, and which
allows to assign rights to read, create or overwrite files or
files in directories for every single client. It also allows
version control.
Details may be found in in the utftpd.conf and utftpd_make man‐
ual pages.
OPTIONS-c, --config-file FILE
Use FILE as configuration file. This has to be a cdb database
file. See the utftpd_make manual page for how to generate this
file, and the utftpd.conf.5 manual page more information about
the input file format of utftpd_make. This file may reside out‐
side the chroot()ed area (this also means the filename should be
relative to the real root directory).
If this option is missing utftpd will fall back to old style
compatibility, see above.
-C, --global-chroot DIR
utftpd shall change its working directory to DIR, and invoke
chroot(".") magic after that. This will be done before the con‐
figuration file is read.
-d, --global-chdir DIR
utftpd shall change its working directory to DIR. This is done
after a global chroot (see the -C option above).
-u, --global-uid NAME_OR_NUMBER
utftpd shall change its user ID to NAME_OR_NUMBER, which may be
a number or a name. In case of a name it will be resolved at the
start of utftpd. The change to the new user id will be done
after a possible global chroot.
You may specify a group as well: Use the USER.GROUP form for
that (or leave out the USER to change only the group).
-v, --verbose
Be verbose (to syslog).
In case i screwed something up: short options use the same arguments as
the long ones
ORDERutftpd will, upon startup, in that order:
receive the first packet from remote (it needs the address of the peer,
to find his data in the configuration file). [just for the records: it
can't use MSG_PEEK here because that would make inetd dance wild. Uah.]
This needs to be done here and now simply because this packet has to be
read, else awful things happen if utftpd exits before it reads the
first packet.
open a syslog connection
open the configuration file, so it may reside outside the chrooted()
area (see the --config-file option). This step is not done in tradi‐
tional mode.
resolve user / group names from a --global-uid option.
chdir and then chroot to the --global-chroot directory, if given.
change user/group IDs to the --global-uid values, if any.
chdir to the --global-chdir directory, if given.
read the configuration file see the --config-file option. This step is
only done if a configuration file has been given on the command line.
close the configuration file This step is only done if a configuration
file has been given on the command line.
go to daemon mode: fork itself in the background
VERSION CONTROLutftpd knows about version control. If it's activated in the configura‐
tion file and the requested file has been put under version control
(which you have to do yourself) then utftpd will
on GET requests (RRQ) try to check out the latest revision and send
that. It will never care about checked out copies it finds lying
around.
on PUT requests (WRQ) out an editable copy, receive the file and then
check them in. It will deny access if the checkout fails. This behav‐
iour allows you to manually check out a file, edit it, check it in
again, without having to fear that utftpd overwrites the file you are
editing, and is also the right way to not open a race condition (think
of two clients wanting to write the same file, although this is a
stupid thing to do anyway).
SCCS is preferred over RCS.
It's a usually not a bright idea to put binary files under revision
control: VC systems tend to dislike them. Some implementations may be
ok, so GNU RCS seems to work find, provided it also has GNU diff avail‐
able.
Version control support is not available in traditional access control
mode.
SEE ALSOutftpd_make(8), utftpd.conf(5), RFC 1350, RFC 2348, RFC 2349.
utftpd(8)
