tftp ======================================================================== This package provides 'tftp-hpa', an enhanced version of the BSD TFTP client and server. It possesses a number of bugfixes and enhancements over the original. It has been made portable and will work on pretty much any modern Unix variant. That having been said, however, tftp is an atrocious, repulsive security horror freak show, with ZERO authentication. Fortunately it is only used in specialized situations (primarily these days in development of embedded software via direct connections or protected local networks). Runtime requirements: cygwin libwrap0 (?) libgcc1 libreadline7 (?) csih Build requirements: autoconf2.5 automake1.11 (for config.guess & config.sub) binutils cygport gcc4-core gettext-devel libwrap-devel make readline (to enable readline support in tftp client) Canonical website: http://freshmeat.net/projects/tftp-hpa/ Canonical download: ftp://ftp.kernel.org/pub/software/network/tftp/tftp-hpa/ License: BSD (3-clause) http://openbsd.wikia.com/wiki/OpenBSD%27s_BSD_license Language: C ======================================================================== Build instructions: unpack tftp-5.2-X-src.tar.bz2 if you use setup to install this src package, it will be unpacked under /usr/src automatically cd /usr/src cygport tftp-5.2-X all This will create: /usr/src/tftp-5.2-X-src.tar.bz2 /usr/src/tftp-5.2-X.tar.bz2 /usr/src/tftp-server-5.2-X.tar.bz2 ======================================================================== Port Notes: This is the cygwin port of tftp-hpa, an enhanced version of the BSD TFTP code, modified to improve portability and to add IPv6 support. The upstream code is maintained by H. Peter Anvin, hence the -hpa. The tftpd server can be run as a service in several different ways. All of these mechanisms require that a normal "unprivileged" user named 'tftpd' exists. On Windows XP (64bit, but not 32bit), Windows NT Server 2003, Windows Vista, and above, they also require that a special "privileged" user (usually, 'cyg_server') exists. To create these user accounts if they do not already exist, run the tftpd-config script as Administrator. It is recommended that the xinetd method be used: first, install and configure xinetd itself using xinetd-config (as Administrator). Make sure it is working properly, then configure tftpd for use using the tftpd-config script (again, as Administrator). Finally, follow the instructions in option #1 below... 1) Using the xinetd superserver (see that package's documentation for instructions on installing and configuring it). This tftp-server package provides a default xinetd startup script for tftpd (/etc/xinetd.d/tftp): simply change the line that reads: disable = yes to disable = no and restart xinetd. See the note below concerning the 'drop privileges' behavior of this new tftpd implementation. 2) Using the inetd superserver (see the inetutils package documentation for instructions on installing and configuring it). Uncomment the following line in /etc/inetd.d/tftp: tftp dgram udp wait root /usr/sbin/tftpd tftpd -c -p -u tftpd -U 022 -s /var/lib/tftpboot and restart inetd. See the note below concerning the 'drop privileges' behavior of this new tftpd implementation. 3) As a standalone windows service, using the cygrunsrv helper app. The simplest way to do this is to use the tftpd-config script, as follows: tftpd-config --standalone For more control, other options are available: tftpd-config --standalone \ --args "-L -c -p -u tftpd -U 022 -a 192.168.2.1 -s /var/lib/tftpboot/" You may also want to pass the following options to tftpd-config (see tftpd-config --help): --privileged --user cyg_server --pwd [cyg_server_password] The options passed after --args will be used when launching tftpd itself. By default, the following args value will be used, when installing tftpd as a standalone server: -L -c -p -u tftpd -U 022 -s /var/lib/tftpboot/ See the tftpd(8) man page for more information, but in the example above: -L: run the server in standalone mode, rather than from a superserver such as inetd or xinetd. Also, do not 'detach' but run in the foreground. This is necessary when using cygrunsrv to host unix daemons as windows services (which tftp-config --standalone does). -c: clients will be able to create new files under /var/lib/tftpboot -p: world read/write on files is not required; all that matters is that the tftpd user itself has read or write access. Thus, to "protect" files from being overwritten by clients, either change the owner of the "protected" file (leaving o+r read access) or remove tftpd's write permission (u-w). -u: tftpd will drop privileges, setting its user id to that of the specified user (by default it will drop privileges to the 'tftpd' user). -U: Any files uploaded to the server will be created using the umask 022 (that is, without group or world write permission). -s: tftpd will serve files from /var/lib/tftpboot, and will chroot() to that directory before dropping privileges. This provides a small amount of additional security: but on cygwin it is unwise to rely on chroot() as you would on "real" unix. -a: Specify the IP address of the interface on which tftpd will listen for incoming connections. By default, tftpd will listen on all interfaces. tftpd-config will create a 'tftpd' unprivileged user, and will ensure that a special privileged cyg_server user exists if needed. If running on Windows XP 64bit (but not 32bit), Windows NT Server 2003, or Windows Vista or above, then tftpd must be launched using a special privileged cyg_server account (and not the LOCAL SYSTEM account). Thus, there are TWO accounts involved with tftpd: the privileged user (cyg_server) or LOCAL SYSTEM on older Windows OS's, and a non-privileged user (tftpd, in this case). See 'Dropping Privileges' below. The privileged user is specified using the --user option to tftpd-config. Also, if using an older Windows OS where LOCAL SYSTEM may be sufficient, you can force tftpd to use the special cyg_server account by passing the --privileged option to tftpd-config. If the privileged user account will be used, then you may pass its password on the command line using --pwd, or tftpd-config will ask for it. If you want to install the tftpd service manually as a standalone service, without the assistance of the tftpd-config script, you can use cygrunsrv directly: cygrunsrv -I tftpd -u cyg_server \ -a "-L -c -p -u tftpd -U 022 -a 192.168.2.1 -s /var/lib/tftpboot/" \ -p /usr/sbin/tftpd Note that the user specified inside the -a option with -u (e.g. 'tftpd' in the example above) must already exist on your machine. If running on Windows XP 64bit (but not 32bit), Windows NT Server 2003, or Windows Vista or above, the '-u cyg_server' is required, and the special, privileged cyg_server user must exist (run 'tftpd-config --standalone' to ensure this). On older versions of Windows, the '-u cyg_server' can be dropped, and the service run under the LOCAL SYSTEM account. In either case, tftpd will chroot to the specified directory, change its user id to the "inner" -u tftpd user, and drop all elevated privileges. Dropping privileges: -------------------- The tftp-hpa tftpd server differs from inetutils one, with respect to how user privileges are handled. The inetutils tftpd requires that tftpd be executed as 'nobody' or some other unprivileged user; this is specified by the fifth element in the inetd.conf recipe in option #2 above, or by the 'user:' entry in the xinetd.d/tftp configuration file in option #1, or by the '-u USER' argument passed **to cygrunsrv** in option #3. However, tftp-hpa uses chroot to enforce the '-s' (--secure) option, and should instead be spawned by xinetd/inetd/cygrunsrv as root (which, you may recall, on cygwin actually means "the privileged user under which inetd itself is running". Since this name may vary -- but is usually 'cyg_server' -- we use 'root' as a placeholder for that privileged user in inetd and xinetd configuration files). However, this "launch as" user name should not be confused with the '-u USER' argument passed to tftpd ITSELF. tftp-hpa's tftpd will drop privileges and change to the specified (-u) unprivileged user after chrooting. Even if '-u USER' is NOT passed to tftpd, it will automatically drop privileges to the default 'tftpd' user -- and will exit with error if unable to do so. In only ONE case will tftpd remain running as a privileged user during a transfer: if the configuration specifies that tftpd is launched with the '-u root' option. Don't do that. Now, you may actually see a 'tftpd' process running as a privileged user when launched by inetd/xinetd/cygrunsrv -- this is expected. However, that tftpd process will spawn a *child* tftpd process to handle each individual transfer, and that *child* process, the only one that actually reads/writes data, will drop privileges and will run as the 'tftpd' unprivileged user. You can verify this by performing a transfer of a very large file and observing the processes running on the server. Also, if you have syslog running, you can monitor the /var/log/messages (if you have syslogd or syslog-ng installed and running) for entries such as: tftpd: PID 3768: uid=1013: handling transfer: server->client In my case, the user id 1013 corresponds to the unprivileged tftpd user. If you don't have syslogd or syslog-ng installed or running, then similar log entries will appear instead in the Windows Event Log -- on Vista, this can be viewed using Control Panel->Administrative Tools->Event Viewer Windows Logs->Application Permissions and other notes: ---------------------------- When using the '-s /path' option, there can only be one path that tftpd will serve to clients. Without -s, there can be any number of such paths, BUT there should ALWAYS be at least ONE path -- otherwise tftpd will grant to clients access to your entire system. Each directory should be owned by the tftpd user, with either 555 or 755 (r-xr-xr-x or rwxr-xr-x) permissions. The contents of each should be user-, group-, and world- readable. If you wish to allow uploads from clients, each target file should already exist on the server (*), and the file should be user-, group-, and world- writable. (*) unless the tftp-hpa extended option '-c' is used, which allows clients to create new files on the server Note that by default (when using a superserver like inetd or xinetd), tftpd will be launched using the following options: -c -p -u tftpd -U 022 -s /var/lib/tftpboot As described above, the default options for tftpd when installed as a standalone server are the same, but with the added '-L' option. So: -c: clients will be able to create new files under /var/lib/tftpboot -p: world read/write on files is not required; all that matters is that the tftpd user itself has read or write access. Thus, to "protect" files from being overwritten by clients, either change the owner of the "protected" file (leaving o+r read access) or remove tftpd's write permission (u-w). -u: tftpd will drop privileges, setting its user id to that of the unprivileged 'tftpd' user -U: Any files uploaded to the server will be created using the umask 022 (that is, without group or world write permission). -s: tftpd will serve files from /var/lib/tftpboot, and will chroot() to that directory before dropping privileges. This provides a small amount of additional security: but on cygwin it is unwise to rely on chroot() as you would on "real" unix. tftpd supports tcp_wrappers using the libwrap0 library. This provides simple IP-based access control. To allow a particular client or subnet to access the tftpd service, add something like the following to /etc/hosts.allow: tftpd: 192.168.1.0/255.255.255.0 Finally, on Windows XP and above, you may also need to allow port 69/UDP through the Windows Firewall (or whatever firewall software you are using. You ARE using firewall software, right?) In Windows Vista, this can be done by launching a cmd shell 'as administrator', and issuing the following command: netsh advfirewall firewall add rule name="tftp" action=allow protocol=UDP dir=in localport=69 Client operation: ----------------- Note that tftp defaults to "ascii" transfers. This is probably not what you want (line ending translation on the binary files that tftp is normally used to transfer is not ideal!). So, remember to use '-m binary'. $ tftp -m binary tftp> get where is either an absolute path, that matches one of the values on the server, or a relative path. However, the downloaded file will be stored in tftp's current working directory. The path information is relevant only on the server; the client uses only the basename of tftp> put where is either an absolute path, that matches one of the values on the server, or a relative path. However, the uploaded file will be read from tftp's current working directory. The path information is relevant only on the server; the client uses only the basename of . Furthermore, the target must *already* exist on the server, with user-, group-, and world- write permissions (unless the tftp-hpa extension option '-c' was used in launching the server, which allows clients to create new files). Finally, on the *client* machine, you may need to allow a 'program exception' in your firewall for the tftp client. The tftp protocol works by creating a new connection from a random high port on the server (e.g. NOT 69) to the port from which the client originally contacted the server (e.g ALSO a random high port, not 69), it is difficult to describe an appropriate firewall rule on the client to allow tftp -- without stateful support. Unfortunately, the windows firewall does not have a module for stateful support of the tftp protocol. Therefore, on the client machine you will need create a global exception for the tftp.exe program itself. ======================================================================== Port History: ----- version 5.0-3 -- 2010-11-20 ----- * Initial release (replaces portions of inetutils) * Fix IPv6 bug. * Correct typos in tftpd-config. ----- version 5.0-2 -- 2010-11-16 ----- * Unreleased. * Revised cygwin README. Updated tftpd-config script messages. * Enable IPv6. * Enable pathname remapping. ----- version 5.0-1 -- 2010-10-nn ----- * Unreleased. Packaged by: Gernot Hillier Charles Wilson