Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow
Дата
Msg-id 3D62622E.20903@joeconway.com
обсуждение исходный текст
Ответ на Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
Ответы Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Список pgsql-hackers
Tom Lane wrote:
> "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> 
>>>I'd like to see something done about this fairly soon, but it's not
>>>happening for 7.3 ...
>>
> 
>>Does anyone have an idea about what other functions are affected by this?
> 
> 
> As a first approximation, every output function for a built-in
> pass-by-reference datatype will show this same behavior.  cash_out is
> just getting picked on because it was the one mentioned in the first
> complaint.  For that matter, every input function for any datatype
> has the same problem:
>     regression=# select cash_in(2);
>     server closed the connection unexpectedly
> 
> Let's see ... I count 264 standard pg_proc entries that are declared
> with one or more "opaque" parameters.  Many but by no means all are I/O
> functions.  There are another 13 standard functions declared to return
> "opaque".  To plug the hole in a credible fashion we'd need to do
> something about every one of these; so belay that last suggestion that
> just implementing a "C string" pseudo-type would be enough to be
> meaningful.

Is there ever a reason for a user to call a function with an opaque 
parameter directly? If not, can we simply REVOKE EXECUTE for these 
functions?


Joe



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: bison news
Следующее
От: "Ross J. Reedstrom"
Дата:
Сообщение: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in