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