Re: Stats Collector Error 7.4beta1 and 7.4beta2 - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: Stats Collector Error 7.4beta1 and 7.4beta2
Date
Msg-id 3F57DA85.7040902@Yahoo.com
Whole thread Raw
In response to Re: Stats Collector Error 7.4beta1 and 7.4beta2  (Adam Kavan <akavan@cox.net>)
List pgsql-hackers
They are both structures of type sockaddr_in (sin_family 2 is AF_INET 
whereas sin_family 10 would've been AF_INET6), and all relevant fields 
of the structure look the same to me. The problem lies in the padding 
bytes that make sockaddr_in the same size as sockaddr.

Since the static structure pgStatAddr is supposed to be initialized to 
nul bytes by the compiler and now does not contain those in the padding 
area, my guess would be that getsockaddr() is actually writing garbage 
into that padding area. This is a nasty change, as one cannot compare 
two addresses for equalness with memcmp() any more just because of 
sloppy programming in the IP stack.

Well, the correct fix would be to compare only the relevant parts of the 
addresses, depending on the address family type.

I personally wouldn't worry too much about removing the check entirely. 
If you got a hacker wasting his time and bandwidth with screwing up your 
statistic collector daemon by sending faked UDP packets to some guessed 
port number (it's only visible in the netstat output on your local 
machine), I think he's done with all the rest of his TODO for the day 
and you'll soon face other problems than that.


Jan

Adam Kavan wrote:

> At 06:49 PM 9/4/03 -0400, Tom Lane wrote:
>>Hmm.  Could you look and see what the actual values are in each address?
>>
>>                         regards, tom lane
> 
> I don't really know the layout of these structures so I dumped them to a 
> file and attached them.  The first 16 bytes is from fromaddr and the second 
> is from pgStatAddr.
> 
> --- Adam Kavan
> --- akavan@cox.net 

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



pgsql-hackers by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: Seqscan in MAX(index_column)
Next
From: Tom Lane
Date:
Subject: Re: Stats Collector Error 7.4beta1 and 7.4beta2