Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
utftpd.conf(5)		      File Formats Manual		utftpd.conf(5)

       utftpd.conf - rules for utftpd

       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).

       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

       Classes (which other people may or may not call templates) allow	to de-
       fine defaults variable assignments:

	     class read_ok {

       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.

       A  client  definition  consists	of  an address specification, optional
       class defintions, and variable assignments.  An example:

	     class base	{
	     # 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 readwrite_ok { name="localhost"}
	     client,etc_ok { name="tirka"}

       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.

       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-

       Adresses	may be spefified as follows:

       Be  careful with	the / masks: The slash makes utftpd_make create	on en-
       try in the database file	for every ip address matches.
       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):

	     # may	write
	     client {write="/"; }
	     # allow the whole 194.245.80.* to read
	     client 194.245.80.	{read="/";} 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.

       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.

       When  utftpd  looks for a configuration variable	it will	first look for
       that variable in	a cdb entry for	(e.g., the IP address  of  the
       client),	 then in an entry for 1.2.3., then 1.2., then 1., and then de-

       Only the	first occurance	of a variable will be honored.

       Given the following example:

	     client {
	       dir="/" ;
	       read=${dir}; write=${dir}; create=${dir};
	     client 194.245.80.	{
	       read="/" ;
	     client default { read="/tmp" }

       The  machine  may	read,  write  or   create   the	  file
       /  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 /, 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  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).

       utftpd(8), utftpd_make(8)



Want to link to this manual page? Use this URL:

home | help