|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
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
--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.
In case i screwed something up: short options use the same arguments as the long ones
-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).
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 cant 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
utftpd knows about version control. If its 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.
Its 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.
utftpd_make(8), utftpd.conf(5), RFC 1350, RFC 2348, RFC 2349.