Re: [ITP] tftp-hpa 5.0

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

On 10/1/2010 10:34 AM, Gernot Hillier wrote:
>> We'll need to coordinate the release of tftp-hpa

Hmmm...now that I think about it, it would be really great if the
package name(s) themselves were simply
	tftp-5.0-N
	tftp-server-5.0-N
Users aren't going to CARE that the implementation/source came from the
'tftp-hpa' distribution.

Mandriva packages tftp-hpa as plain old "tftp" and "tftp-server".

SUSE packages both client and server in a single package called "tftp"
(not "tftp-hpa"):
https://build.opensuse.org/package/view_file?file=tftp.spec&package=tftp&project=openSUSE%3AFactory

Fedora also appears to provide tftp-hpa, and names the resulting
packages "tftp" and "tftp-server" (and tftp-debuginfo)
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1995280

Debian does package as "tftp-hpa" -- but that's because Debian ALSO
provides the netkit-based "tftp" package.  apt can handle
conflicts...but setup.exe doesn't; see below.


> with an update to
>> inetutils (removing its tftp*).  
> 
> Hmmm, wouldn't it make sense to also split inetutils and keep tftp* in a
> separate package? So users are not forced to switch?

setup.exe doesn't have any provision for specifying conflicts.  So, we
can only have one (current) package that provides any specific file
(such as /bin/tftp.exe or /usr/sbin/tftpd.exe).

So, either
 (1) one package provides tftpd.exe and the other provides tftpd-alt.exe
 (2) one package provides tftpd-inetutils.exe and the other provides
tftpd-hpa.exe, and both packages register with the 'alternatives'
framework, or
 (3) we only have a single tftp-ish package at all

(1) -- Yuck!
(2) hard to manage; not clear how cygrunsrv and Windows services will
interact with the 'alternatives' framework given that it employs symlinks.

(3) is much simpler.

This is the same reason I *removed* inetutils' rsh and rshd
implementations, when creating the netkit-based separate packages.
Besides, inetutils' implementations (of rsh, but also tftp and
everything else) have no support for IPV6 -- while tftp-hpa nominally does.

> Done.
> 
> Please find an updated version here:
> 
> wget -r -np -nH -R "index*" \
> 	http://h1629194.serverkompetenz.net/tftp-hpa-2/
> As you can see, I also documented my patch which removes the setreuid()
> switch to nobody for tftp-hpa. Is this ok in your eyes?

I have a number of concerns with the actual port:

First, your docu says:
	This is the cygwin port of tftp-hpa. For now, we deactivated the
	following features (--without-xxx to configure script) to ease
	the porting:
	* tcpwrappers
	* remap
	* readline
	* ipv6
While I don't really have any issues with remap, I wonder why you
dropped tcpwrappers? It adds no complexity to the build, and helps -- to
a certain degree -- with some of the security issues endemic to the tftp
protocol.  (Especially as tftpd-hpa operates in such a way that you
*can't* call it via the 'tcpd' utility in inetd.conf).

Also, the whole *point* of obsoleting inetutil's version is because it
is not capable of support IPv6 -- but tftp-hpa is.

So, I really think you should enable IPv6.  Now, that means a lot of new
porting work, because there are ALWAYS issues with porting IPv6
networking to cygwin/win32...see the rsh package's patches (also, xinetd).

Also, readline support is probably a pretty nice advantage of the
tftp-hpa client over the inetutils one...but that's a minor issue.


Now, as far as dropping privileges...that's a tricky one.  First, your
assumption that most people will run tftpd as a standalone service under
cygrunsrv is probably false. I imagine most people will use a
superserver (inetd or xinetd) instead.

And...the SYSTEM user may or may not be the correct one; the parent
superserver might be running as the special cygserver user -- which has
even more privileges than Administrator.

Now, IMO, you NEVER EVER EVER EVER want to run the tftp server as ANY
privileged user at all: cygserver, Administrator, SYSTEM, ...

NO.

tftp is SO incredibly insecure it boggles the mind.  Letting random
*unauthenticated* users upload to your machine (or download), using the
credentials of Administrator?  Using client-specified paths?  Not just
no, but hell no. (Recall that cygwin doesn't *really* jail chrooted
processes; they can always use win32 functions to "break out").


So, IMO the "-u USER" option is even more useful on cygwin, so we really
need for that to work, and not simply disable it (which may mean that
cygwin-specific "change user" code needs to be added).  Now, on unix,
tftpd without -u acts as if it were "tftpd -u nobody".  Unfortunately,
there is no default unprivileged user like "nobody" on win32.

It's probably a good idea for the tftp package to include a tftpd-config
script to create one...  Probably inetutils' iu-config (for the sake of
inetd) and xinetd's xinetd-config should do this, too. (I'd probably
call it 'cygnobody' for clarity).  Or, (perhaps and?) tftpd-config
should create a 'tftpd' user and group...

Anyway, then the default behavior would be as if '-u cygnobody' on cygwin...

We should also install the tftp-xinetd (suitably patched, if required)
into /etc/xinetd.d/  (and use cygport's make_etc_defaults feature)


Basically, there still appears to be a lot of work involved in fully
porting tftp/tftpd, so that the new version actually *adds* capability
and justifies retiring the existing inetutils one.

I'll help, but it'll be a long slow process; my time is pretty limited
right now.  I'll try to come up with a preliminary additional patch that
helps with the -u issue over the next week.  We should probably take
additional discussions offline, just to keep from annoying the list with
ongoing development.

>> I'd also like to "move" the relevant documentation from
>> /usr/share/doc/Cygwin/inetutils.README to
>> /usr/share/doc/Cygwin/tftp-hpa.README (and
>> /usr/share/doc/Cygwin/tftp-hpa-server.README?)
> 
> Anything I should do here?

Well, first we need to actually *complete* the port. Then we can move
over any documentation, rewriting as necessary to reflect the new reality.

I don't mean to be discouraging; I think it's great that you've stepped
up to help with cygwin's networking clients and servers.  However, IMO
networking servers are *the* most complex programs to get working
correctly and securely (*) under cygwin, since it requires knowledge of
both unix programming and networking, but also Win32 oddities -- and the
weird way cygwin sometimes interacts with those.  So, just like I did,
you have a learning curve ahead -- it'll be an adventure!

(*) well, as secure as the underlying protocol allows, anyway

Oh, and FYI...it's probably not a good idea to rely on mailing list
messages from 2003, especially when dealing with cygwin behavior
relating to userid, security, networking... ('see...mail thread
"setreuid" on the cygwin mailing list
(http://www.cygwin.com/ml/cygwin/2003-10/msg00914.html) for further
discussion')

A *lot* has changed in seven years!

--
Chuck