utftpd(8)

NAME
utftpd - a trivial file transfer protocol (TFTP) server

SYNOPSIS
utftp [options] [dirs]

DESCRIPTION
utftpd 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 manual 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 outside 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 configuration 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

ORDER
utftpd 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 traditional 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 CONTROL
utftpd knows about version control. If it's activated in the configuration 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 behaviour 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 available. Version control support is not available in traditional access control mode.

SEE ALSO
utftpd_make(8), utftpd.conf(5), RFC 1350, RFC 2348, RFC 2349.