Re: [ITP] tftp-hpa 5.0

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

On 10/4/2010 5:28 AM, Corinna Vinschen wrote:
> On Oct  4 10:24, Gernot Hillier wrote:
>> Am 01.10.2010 17:47, schrieb Charles Wilson:
>>> 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).
> 
> Chuck, for the dumb of us, can you please reiterate in a few words
> what problems you're talking about?  I'm kind of in trouble to think
> of any Cygwin-specific IPv6 problem apart from some border cases.
> I have at least two packages which I use IPv6 with, openssh and
> syslog-ng, and I have no trouble with them.

It's not so much *cygwin*, as *windows*.  If a socket is opened to
listen for both IPv4 and IPv6 packets, then *all* received packets will
appear as IPv6 ones -- IPv4 ones will show up "wrapped" as
::ffff::71.15.23.51 or something.

So, if the app listens for both packet types, it really better support
IPv4-in-IPv6 addressing. Many of them don't.

This isn't really a cygwin bug, but an application bug exposed by how
windows, underneath cygwin, handles mixed-mode sockets.

Also, when iterating interfaces, windows returns *a lot* more than the
obvious ones (like, my simple laptop with wireless + wired returns about
a dozen...some are VPN tunneling devices, etc) and IIRC lists the IPv6
ones first.  There was also some issue, the details of which escape me
right now, related to IPv6 localhost ::1 and 127.0.0.1.  But the point
is, on a windows machine the application MUST be able to deal with
multi-homed interfacing.  A lot of the older apps aren't.


>> We can for sure try to re-enable and fix all these issues, but as for
>> you, my time for these tasks is also quite limited and I can't promise
>> quick results here...
> 
> IMHO a new tftp only makes sense if it has some visible advantages
> over the old one.  Tcpwrappers, readline and IPv6 shouldn't be that
> tricky.

Yes on the first two...we'll just have to see on IPv6.  Maybe tftp-hpa
is maintained well enough upstream that we won't see the problems that
cropped up wrt inetutils.

> But we're all volunteers here.  If it's not a security related problem,
> we're not asking for "quick".

Yep.

>> Hmmm, anyone running tftpd should know that (s)he should protect it from
>> any productive network as it's insecure by design. In my eyes, putting
>> tftpd behind an effective firewall is just the right answer here. Any
>> effort spent to improve tftpd's security concept *if you don't trust his
>> peers* will only raise the security bar from 10 to 12% IMHO.
> 
> Nevertheless, running tftp with admin privileges is not a good idea.
> Maybe you should at least try to seteuid to uid 501, the default uid
> for the "Guest" user.

I was thinking of borrowing a page from openssh's privsep 'sshd' user,
and using a -config script to create a 'tftpd' user.  I did some work
over the weekend, and the way I have it structured now, tftpd will

  (a) try to setuid to 'tftpd' (after chrooting, if -s is specified)
  (b) unless -u USERNAME, in which case it will setuid to that user
  (c) but, if USERNAME specified as the argument to -u is 'root', then
      it will act like inetd/xinetd, where 'root' is taken to mean
      'whatever privileged user I'm actually running as now': e.g.
      setuid (getuid())

Unlike 'regular' tftpd, you're supposed to initially launch tftpd-hpa as
a privileged user, so it can chroot if required. It then drops
privileges by changing all of its IDs.

If anything fails, tftpd logs the error and exits; it never attempts to
"keep going" without dropping privileges -- unless you told it to remain
in a privileged state via '-u root'.

I've also moved the "missing" arpa/tftp.h header from inetutils to this
package, and restructured the installation process to use the package's
INSTALLROOT support instead of configuring with ${D} in the --prefix
argument.  It builds and creates the packages, but...

I just have to test it.

(I've done nothing with regards to IPv6, readline, or tcpwrappers yet).

The tftpd-config script also gives you a choice between installing tftpd
as a superserver client, OR as a standalone service (in which case, the
server needs to be installed to run as cyg_server, but have the -u tftpd
argument).  On a virgin machine, this means that tftpd-config would need
to create both the cyg_server privileged user AND the tftpd unprivileged
user.  It's very similar to ssh-host-config.

Anyway, once I've done that, I'll send|post the updated tarballs before
beginning to address IPv6 et al -- which might not happen for a week or two.

>>> We should probably take additional discussions offline, just to keep
>> >from annoying the list with ongoing development.
>>
>> Sure. I'll come back to you via private mail as soon as I had a
>> detailed look on all your points...
> 
> I disagree.  We already had a lot of discussion about porting packages
> to the Cygwin distro on this list.  It might be worth to keep it here,
> unless the two of you want to share secrets :)

OK.

I was just trying to avoid bouncing a bunch of iterations of the -src
package back and forth on Gernot's and my websites; instead just
emailing them back and forth.  Nobody wants to see tarballs as
attachments to list messages...so if we keep the discussions here,
tarball trading has to move to websites.  Which is a pain -- but doable.

--
Chuck