Re: Stats Collector Error 7.4beta1 and 7.4beta2

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: Stats Collector Error 7.4beta1 and 7.4beta2
Дата
Msg-id 3F5EBBAA.4060602@Yahoo.com
обсуждение исходный текст
Ответ на Re: Stats Collector Error 7.4beta1 and 7.4beta2  (Kurt Roeckx <Q@ping.be>)
Ответы Re: Stats Collector Error 7.4beta1 and 7.4beta2  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Stats Collector Error 7.4beta1 and 7.4beta2  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers

Kurt Roeckx wrote:

> On Tue, Sep 09, 2003 at 02:10:20AM -0700, Kevin Brown wrote:
>> > 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?
> 
> The reason I used a memcmp() instead of dealing with the
> structure members themself is because it was easier.

:-/

> 
> Checking that they're the same address family is easy, and if
> they're different the kernel is really broken.

Agreed.

> 
> For the addresses and port, in case of IPv4, you have to cast it
> to sockaddr_in *, and compare the sin_addr and sin_port like
> before.

Using a decent C compiler (and who compiles PostgreSQL without) this 
should reduce to some sort of a 32-bit and another 16-bit comparisions 
... no?

> For IPv6 you could do it with a memcmp on the sin6_addr part, and
> put it inside an #ifdef HAVE_IPV6.
> 
> If you want to write code to compare 2 addresses, please make it
> a general function and place it in ip.c.
> 
> Anyway, I'm happy with the current use of recv().

I disagree here. The clean and secure way is still to do *some* check 
(because we carefully don't assume that all OS's behave like some 
manpages happen to agree to). The performant way is to do it with 
information that is available without any extra system call.

So either we do the random signature thing, which I would favor as a one 
time be all, end all solution - or you do the actual from-address based 
implementation by restoring the old IPV4 behaviour and adding correct 
IPV6 behaviour.


Jan

-- 
#======================================================================#
# 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Stats Collector Error 7.4beta1 and 7.4beta2