Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
От | Nigel J. Andrews |
---|---|
Тема | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in |
Дата | |
Msg-id | Pine.LNX.4.21.0208201228560.1042-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Ответ на | Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
|
Список | pgsql-hackers |
On Mon, 19 Aug 2002, Tom Lane wrote: > Justin Clift <justin@postgresql.org> writes: > > From the info still around, this looks to mean that the cash_words() > > problem was fixed, but the cash_out() problem was harder to fix. > > > Tom/Bruce, is that correct? > > The cash_out problem can't really be fixed until we do something about > subdividing type "opaque" into multiple pseudo-types with more carefully > defined meanings. cash_out is declared cash_out(opaque) which does not > really mean that it accepts any input type ... but one of the several > meanings of "opaque" is "accepts any type", so the parser doesn't reject > cash_out(2). > > 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 stop gap measure to remove the *known* DoS issue how about changing the pg_proc entry to restrict input types, i.e. not cash_out(opaque)? cash_words is already listed as only taking the money type is cash_out really that different? On a related topic cash_out() is listed in pg_proc as returning an int4 but doesn't the code clearly show that is incorrect? -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
В списке pgsql-hackers по дате отправления: