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