utftpd.conf(5)utftpd.conf(5)NAMEutftpd.conf - rules for utftpd
DESCRIPTIONutftpd.conf containes rules for utftpd. It cannot be used by utftpd
directly, but needs to be converted through use of utftpd_make(8).
FORMAT
Empty lines in the input are ignored, as are lines which start with a
hash sign (#). All other lines may either be V1 format definitions
(compatability to versions <0.2.1, see below), class definitions or
client definitions.
V1 and V2 format may be intermixed, although i suspect that this will
not look too beautiful.
V1 is described in an own section. All other sections deal with the V2
format.
CLASS DEFINITION
Classes (which other people may or may not call templates) allow to
define defaults variable assignments:
class read_ok {
read="/tmp"
}
Classes may inherit from other classes:
class write_ok { write="/tmp" }
# a class which only inherits:
class readwrite_ok: read_ok,write_ok;
class readwrite_ok2: read_ok {write="/tmp";}
The second and third class are identical.
It's possible to assign more than one variable to a class:
class rcs { rcs-co=/bin/co; rcs-ci=/bin/ci }
Here is something which doesn't work:
class base {read="123";}
class c1:base { read+="456" }
class c2: { read="789" }
class conflict:c1,c2;
`c1' and `c2' conflict: both define `read'. There is no simple and
clean solution to this problem.
CLIENT DEFINITION
A client definition consists of an address specification, optional
class defintions, and variable assignments. An example:
class base {
base="/tftpboot";
images="${base}/images/";
config="${base}/config/"
}
# allow read access to the own config file and the images directory.
class read_ok { read="${config}${name}:${images}"; }
# allow write access to the own config file.
class readwrite_ok:read_ok { write="${config}${name}"; }
# also allow read access to /etc. Don't do that in real life, every user can
# use tftp clients ...
class etc_ok { read+=":/etc/"; }
client 127.0.0.1: readwrite_ok { name="localhost"}
client 194.245.80.2:readwrite_ok,etc_ok { name="tirka"}
STRING REPLACEMENTS
The ${base} thing you can see above will be replaced by the value of
the variable base. It's an error if that variable is undefined,
utftpd_make will stop.
String replacements are done before the strings get written to the con‐
figuration database, not in the daemon. Therefore there is no chance to
replace something by a client IP address.
VARIABLE ASSIGNMENT
There are three forms of variable assignments:
Simple 'var = value' assignments
utftpd_make will stop if the variable is already defined.
'override var = value' assignments
utftpd_make will override a old value (if any) with the new one, other‐
wise it will create the variable.
'var += value' assignments
utftpd_make will append the new value to an old one (if the variable is
not already defined it will be created, `+=' then is equal to a `='
assignment.
ADDRESSES
Adresses may be spefified as follows:
127.0.0.1
127.
194.245.80.2
194.245.80.2/28
194.245.80.2-5
194.245.0.0/16
194.176.0-31.
default
Be careful with the / masks: The slash makes utftpd_make create on
entry in the database file for every ip address matches.
194.245.0.0/16 stands for 65536 addresses, and is certainly a waste of
disk space.
The dash also creates one entry for each match, but 194.176.0-31. only
creates 32 entries.
Please note that only the first entry in configuration file which
matches a given IP address is used. This does not work (but will
silently fail, not lead to an error message):
# 194.245.80.2 may write
client 194.245.80.2 {write="/"; }
# allow the whole 194.245.80.* to read
client 194.245.80. {read="/";}
194.245.80.2 will only be able to write, _not_ to read. I consider
this a feature: TFTP knows no security at all, so i force you to tell
the daemon exactly what to allow. Please note that you should never
give read or write access to your root directory.
utftpd_make dislikes duplicate addresses.
RECOGNIZED VARIABLES
utftpd recognizes the following variables in the configuration file:
chroot change working and root directory to the value. Note that utftpd
needs to have to necessary rights to do so (this probably means it has
still run under root. Use the uid feature to change that. You should
not let utftpd run as root.)
dir change working directory. This just changes the way utftpd inter‐
prets relative file names (those starting without a /) it receives from
clients. Note that you have to specify full paths for the access con‐
figuration variables (below) anyway: utftpd uses full qualified file
names internally.
uid change user/group ID to the value (which may be a name or a number.
Note that, in case of a global chroot, see the utftpd manual page, the
system passwd may not be available anymore).
read specifies a list of directories or the daemon may read. Entries
are separated by colons (as in $PATH). This may use wildcards.
write specifies a list of directories or files the daemon may over‐
write. This may use wildcards.
create specifies a list of directories the daemon may create files in,
or files the daemon may create. Note that the create list does not
include the write list (or vice versa). This may use wildcards.
sccs-get contains the path to the get command of the SCCS system.
sccs-delta contains the path to the delta command of the SCCS system.
If both are given and a SCCS version of a requested file exists then
utftpd will try to use SCCS.
sccs-unget contains the path to the unget command of the SCCS system.
If this and sccs-clean are missing then utftpd will check in unchanged
files. In other words: If one or both of those options are given utftpd
will try to not check in unchanged files under SCCS control. This can
be an important feature if, for examples, your routers automatically
save their configuration to a tftp server every night.
sccs-clean contains the path to the clean command of the SCCS system
(this seems to be non-standard). See sccs-unget for a description.
rcs-ci contains the path to the ci command of the RCS system.
rcs-co contains the path to the co command of the RCS system. If both
are given and a RCS version of a requested file exists in a RCS subdi‐
rectory (meaning RCS/file,v) then utftpd will try to use RCS.
SCCS will be preferred over RCS if both are found. A good place to set
the revision control variables is the default target.
RESOLVING
When utftpd looks for a configuration variable it will first look for
that variable in a cdb entry for 1.2.3.4 (e.g., the IP address of the
client), then in an entry for 1.2.3., then 1.2., then 1., and then
default.
Only the first occurance of a variable will be honored.
Given the following example:
client 194.245.80.2 {
dir="/ohse.de/tirka" ;
read=${dir}; write=${dir}; create=${dir};
}
client 194.245.80. {
read="/ohse.de" ;
}
client default { read="/tmp" }
The machine 194.245.80.2 may read, write or create the file
/ohse.de/tirka or may read, write or create files in a directory with
the same name (if that directory exists, of course). It will not be
able to read a file /ohse.de/serak, which all other machines of the
194.245.80.* range are able to do. Everyone else except the
194.245.80.* range may read from /tmp.
V1 FORMAT
V1 format is deprecated. It may vanish some day, and is left just for
compatibility with versions of utftpd prior to 0.2.1.
V1 format definitions end at the end of the line. They consist of an
address specification (identical to the format used now), a colon, and
one or many variable assignments.
Each assignment consists of a list of variables, each separated with a
comma, which are followed by a pair of parenthesis containing the value
to be assigned (to each of that "list of variables") between them,
after which other variable names may follow:
address-specification: VAR11[,VAR12[,VAR13 ...]] ( value ) [VAR21[,VAR22[,VAR23 ...]] ( next value ) ...]
(really all on one line, please).
SEE ALSOutftpd(8), utftpd_make(8)utftpd.conf(5)
