This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] tftp-hpa 5.0


On Oct  4 11:10, Charles Wilson wrote:
> 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.

Which functions are you talking about?  getpeername?  accept?  readfrom?
getaddrinfo?  All of them?

If so, we could do something about that by massaging the returned
addresses from V4-in-V6 into plain V4 addresses.  Since the memory
region used for V6 can easily contain a V4 address, we don't have
to change any memory allocation or so, just tweak the content of the
sockaddr structure.  Well, except in case AI_V4MAPPED is specified
in getaddrinfo...

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

Well, that's not exactly just a Windows problem.  Any interface can at
any time return more than one V4 and more than one V6 address.  Not only
my Windows machines, but also my Linux machines typically have at least
one V4 and two V6 addresses.  A tool which doesn't grok this is just
horribly broken.  I guess the age of inetutils really shows...

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

Sounds good to me.

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

Just to let you know, I'll be mostly unavailable for the next five weeks
starting this weekend.  If there's something required in terms of the
aforementioned V4inV6 problem, the time to do something is either now or
late in November.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]