FreeBSD Manual Pages
utftpd.conf(5) File Formats Manual utftpd.conf(5) NAME utftpd.conf - rules for utftpd DESCRIPTION utftpd.conf containes rules for utftpd. It cannot be used by utftpd di- rectly, 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 de- fine 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 `=' as- signment. 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 en- try 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 in- clude 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 de- fault. 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, af- ter which other variable names may follow: address-specification: VAR11[,VAR12[,VAR13 ...]] ( value ) [VAR21[,VAR22[,VAR23 ...]] ( next value ) ...] (really all on one line, please). SEE ALSO utftpd(8), utftpd_make(8) utftpd.conf(5)
NAME | DESCRIPTION | FORMAT | CLASS DEFINITION | CLIENT DEFINITION | STRING REPLACEMENTS | VARIABLE ASSIGNMENT | ADDRESSES | RECOGNIZED VARIABLES | RESOLVING | V1 FORMAT | SEE ALSO
Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=utftpd.conf&sektion=5&manpath=FreeBSD+Ports+15.0>