Bug#164768: libc: IPv6 still not correct.
On Thu, Oct 17, 2002 at 10:35:50AM -0400, Ben Collins wrote:
> On Thu, Oct 17, 2002 at 10:49:06AM +0100, Jonathan Amery wrote:
> > Ben Collins wrote:
> > > On Wed, Oct 16, 2002 at 09:50:10PM +0100, Matthew Vernon wrote:
> > > > ssh is using getpeername() in accordance with the manual. The
> > > > structure that getpeername() returns is causing gatenameinfo() to
> > > > barf. That seems to me to be unambiguously a bug.
> > >
> > > Only because kernel 2.2 is broken, not becuase glibc is. The reason is
> > > because kernel 2.2 uses an old obsolete api.
> >
> > Firstly - this is not a bug in sshd - sshd is interacting with libc's
> > API in good faith.
> >
> > Secondly - it is the job of libc to ensure that the APIs it exposes
> > function correctly. If the IPv6 code in 2.2 is incompatible with
> > these APIs then libc should not be attempting to provide IPv6 on
> > systems with a 2.2 kernel, rather than functioning outside of the APIs
> > that it claims to implement.
>
> No, sshd should be checking the validity of the data that is returned to
> it.
sshd does check the validity of its data, and correctly throws an error
because it finds that getnameinfo() returns -1. That is not the problem
here.
Could we at least have some documentation that getnameinfo() with IPv6
addresses is not supported on pre-2.4 (or non-RFC2553) kernels? This is
evidently the state of affairs, and a simple note would help other
programmers to know that this call will fail with a surprising errno. In
response to "nobody sane would use IPv6 on 2.2", well, that may be true,
but that's not exactly obvious to new people who see that the module's
available and some things appear to work - documentation would go a long
way here.
Since you're saying that glibc doesn't want to work around a kernel bug,
I'm sure you can appreciate that we aren't keen on working around what
we see as an inadequacy in glibc either. The mutual unwillingness to
perpetrate workarounds is why this argument has dragged on for so many
months. The proposed solutions in openssh so far seem to have involved
hacks like testing utsname.release to see whether the kernel is 2.2,
which is clearly quite nasty (at least test features, not version
numbers ...).
Is there any compromise we can reach *without* applying hacks that cover
up the fact that glibc doesn't cope with the differently-sized kernel
structure? Perhaps having some documentation in glibc, and outputting a
loud error message in ssh and trying to gracefully downgrade to AF_INET?
--
Colin Watson [cjwatson@flatline.org.uk]
Reply to: