Tom Lane wrote:
> <andrew@dunslane.net> writes:
> > This analysis makes sense - I think using memcmp is clearly wrong here.
>
> Yeah, now that I think about it, we're betting on the kernel to
> faithfully zero all unused bits in addrinfo structures. In an ideal
> world, all kernels would do that, but in the real world it seems like
> a losing bet.
Yeah, I've always been under the impression that it's a bad idea in
general to memcmp() structs, if only because in doing so you make a
lot of implicit assumptions about the structs in question that aren't
necessarily true, especially when dealing with multiple architectures.
Makes me wonder if there are other parts of the code where we're
vulnerable to the same sort of issue...
> I could go for Jan's idea of putting a random key into the messages,
> if anyone feels that we should not trust to the kernel to enforce the
> packet source address restriction. But the memcmp() test seems a clear
> loser given today's discussions.
The test in the 7.3.x code looked reasonable to me, especially if it's
possible to make it work with IPV6 (if it doesn't already). It's doing
basically the right thing, at any rate: directly comparing the actual
fields that are relevant. Does this test represent a significant
performance hit?
--
Kevin Brown kevin@sysexperts.com